Hacker Newsnew | past | comments | ask | show | jobs | submit | tonyjackson's commentslogin

I'll never understand those that insist on doing real work, or gaming, with a laptop. When dealing with a GPU, and especially one made by nvidia, you're battling with the laws of physics. Super hot things make other, nearby things, super hot. Even with proper cooling, nvidia chips overheat and die. Anyone that has had nvidia already knows this. They have a lifetime of a year or two, max.

Get a desktop already. At least then, when your fancy GPU has a meltdown, you can salvage things from the wreckage.


For a lot of us, a desktop is just too big and too much work. A laptop is easy, it's everything right in front of you, it's fast enough, it's cheap enough, and it's portable. Aside from serious business use (trading, rendering, etc), gamers, programmers and data hoarders, there's not really a great reason for the average person to have a desktop anymore.

Laptops that were built with thermals in mind actually do quite well at full load. I used to play a decent amount of games on my Lenovo Y500 when it was new and it could do full load for hours and hours without getting hot. It was still less noisy than my Macbook. The secret is to build a high diameter fan and a wide fan vent. Unfortunately Apple seems to think that being thin is more important. It's certainly easier to market.


Not always possible. I can't speak to gaming, but I use a laptop for "real work" almost exclusively. My reason is because I not only write code at home, but often have meetings or go to a coffee shop to do a demo, etc. There's no way I'm carrying a box and monitor to all those places.

What I trade for portability is performance and I replace the machine more. I just keep everything important stored online and when my laptop dies I grab another and keep going.


real work = putting a load on the CPU, as in making the CPU do work. Your text editor does not count.

In almost every instance of someone using a laptop for heavy CPU work, there is certainly a better, more practical reason to use a desktop. There is no need to sit at a coffee shop and make music, unless you do not have access to a studio or even your parent's garage. Video editing will not be done out in the field. It will, if done professionally, be in a quiet room with the proper equipment. Most of the time, someone that insists that doing either of these is just fine on a laptop, is someone that is young, broke, and doesn't have access to the proper tools for the job. Of course, the person pointing this out will get many downvotes...


I wouldn't downvote you, but real work for me is not my text editor, it's more like:

Compiling Importing and Exporting from a database Photoshop load tests.

Also, I run a web server and database on my machine. It's just a personal preference for me. I do have a mac mini at home that I use also for stuff like video editing.


There are a lot of reasons why someone wouldn't buy a gaming desktop.

1. They just spent $2000+ on a laptop and don't want to / can't afford to spend another $1500+ (desktop + decent display).

2. They only game occasionally.

3. They don't want to own more stuff.

4. Their laptop has a warranty which covers any GPU issues.

In my case all of these apply.


Congrats? You have everything you want, and no license to complain when your Macbook overheats and dies I guess. And you also seem to recognize that it will die. As long as you use the right tool for the right job, sure...


Your case would have much more weight if similarly equipped 2012 Macbook Pros with discrete GPUs were failing at the same rate as their 2011 counterparts.


My case is to use the right tool for the job. If you're gaming on a laptop, you're getting a subpar experience anyway. Unless you're also lugging around an additional keyboard, mouse, and headphones. Which makes the whole laptop convenience a moot point. Or are you really arguing 2012 Macbooks don't get hot when gaming? I don't buy that.


>> Or are you really arguing 2012 Macbooks don't get hot when gaming?

No, I'm saying that the 2012s aren't getting so hot that there have even been remotely same degree of hardware failures as with the 2011 models.

My 2011 MBP just died last week (already replaced the logic board once under AppleCare). I never really played any games on it, so the failure had less to do with the discrete GPU itself than the CPU causing the overheating issues.

The logic boards clearly have a design defect in that they can't handle the heat that the computer runs at under non-gaming load. So contrary to what you said, I think I do have a "license to complain when your Macbook overheats and dies".


These are all very legitimate gripes, and even dangers.

One wrapper I used (think Python/Perl/Ruby), the author did not properly understand how the 0-padding was supposed to be implemented. I was scratching my head for a few hours wondering why messages I encrypted were not being received properly. Turns out, bugs in the C padding code.

The discussion of nonces really needs big flashing warning text and icons. I've seen total disasters with code trying to do nonces correctly, or not even understanding why nonces are important (one VPN package I used had the option of using null nonces, as if it were a feature!)


The ZEROBYTES padding is a source of confusion and bugs, including in bindings. Having to allocate more bytes than the unsealed message in crypto_sign_open() was also the root cause of quite a few unfortunate bugs.

And even when used properly, people always ended up writing wrappers allocating temporary buffers and moving data around in order to add/trim these bytes.

And when people start writing wrappers, it usually means that there is something wrong with the API.

For this reason, libsodium fully supports the crypto_box and crypto_secretbox in a compatible way, but doesn't document them in favor of the "easy" interface, which basically does what everybody was reinventing when writing wrappers for these functions.

How to generate nonces for each operation is described in the libsodium documentation. There are legitimate cases for having full control over the nonce, such as the dnscurve and dnscrypt protocols.

Some bindings such as the Swift bindings (Swift-Sodium) have the box() operation generate and return a nonce in addition to the ciphertext. Less flexible than leaving the responsibility to the developer, but definitely safer, and something that might be added to the library itself. On the other hand, adding more and more functions to do the same thing (because breaking backward compatibility is not an option) isn't good either.


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

Search: