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

Ok, here's one with a log scale so you can clearly see the exponential trend line

https://spectrum.ieee.org/chart-behind-the-three-decade-coll...


“Between 1991 and 2018, the average price of the batteries that power mobile phones, fuel electric cars, and underpin green energy storage fell more than thirtyfold”

THIRTY FOLD ISNT EXPONENTIAL.

Please reevaluate the plan. It likely contains a lot of optimism and a few required miracles


> THIRTY FOLD ISNT EXPONENTIAL.

A * exp(b * t) = A / 30 => b = - log( 30 ) / t

As far as I can see a thirty fold decrease does fit into any exponential curve if you have the right rate constants or times, so I don't really get what you mean with that.


I share your sentiment that DK being a statistical phenomenon actually makes the effect more interesting. I also, however, think that you are being too semantically liberal when you insist that this proves the effect exists. The DK effect is a _psychological_ effect, with a whole lot of psychological theories around it's causes. If the cause is statistical, the psychological effect can no longer be said to exist.

The stasticial phenomenon exists, surely - but I think it will be very confusing for everyone to re-use the same name.


Why, if his monthly bill is 83 cents, and he values his time? Does not using a CDN impact performance in a crippling way that neither me nor the poster you're replying to understands?


The big gain with putting Cloudfront in front of it is you can have HTTPS.


HTTPS gets you better SEO and the ability to be iframe'd from HTTPS sites.


And some security.


And loose 30 mins of your life you’ll never get back. It’s just a person site.


Browsers will light up like a christmas tree if your site doesn't have https.


Performance maybe a little bit, but IIRC you, as the owner of the bucket, pay for bandwidth out.

Putting it being a CDN protects you (at least a little bit) from the possibility of a huge bandwidth bill at the end of the month if someone realizes they can attack your wallet directly by trying to ddos your site.


I agree– AWS bandwidth out is literally 100 times more expensive than CDN and VPN bandwidth out.


indeed, not to mention generous bandwidth rates on vps providers too


*VPS


It takes like 30 seconds to point a Cloudfront distribution at an S3 bucket. Maybe a couple minutes more to set up the domain.


Eh, only if you've done it before. If it's your first time, it can easily take 30 mins to an hour, if you also have to figure out how to host the website on Route 53.


Well, sure, but every suggestion is going to take some time if you've never done it before. It's not like it's an obscure skill that you'll never use, it's pretty handy to know.


I don't think it matters much b/c of the super low volume but I do have it behind Cloudflare free-tier.


> Does not using a CDN impact performance in a crippling way that neither me nor the poster you're replying to understands?

It adds up to 600ms of latency for each roundtrip. A modern website without link rel=preload is several roundtrips– download HTML page, then do JS requests and CSS, so that's ~1.2s of additional latency.

Because he succumbed to AWS' marketing. Surge, mentioned downthread, lets you deploy a folder for free on a worldwide CDN with virtually no setup.


surfboard shape?


Would you mind expanding the acronyms? This is super interesting, but hard to follow (and also somewhat hard to google, apparently Arbr is a bike brand)


Ah, can't edit the comment anymore but:

RCE: Remote Code Execution. It's fairly straightforward, but basically any vulnerability that allows you to run (native) code without physical access to the phone (e.g. when a user visits a website).

ACE: Arbitrary Code Execution. Basically any technique that allows taking control of the execution to execute your own arbitrary code.

ArbR/ArbW/ArbCall: Arbitrary Read, Arbitrary Write, Arbitrary Call primitives. They tend to be the "basic unit" which you can weave together to further poke at things once you've gained ROP.

ROP: Return Oriented Programming, a technique used to take control of execution when you have the ability to overwrite the Return Pointer of the current stack frame (for instance, from a stack buffer overflow). ROP is used because nowadays, most processes adhere to W^X (Write Xor Execute, basically a memory page is never both writable and executable at the same time), meaning we can't just inject shellcode and jump to it anymore. You can find a small tutorial on ROP at [1].

ROP This can then be used to generate various primitives (ArbW can be achieved by weaving together a "ROP Chain" that calls memcpy with the right registers, for instance).

IPC: Inter-Process Communication. Imagine a Unix Pipe, where two processes communicate with each-other over stdin/stdout. This is an example of an IPC. There are other IPC mechanisms (D-Bus, Unix Sockets, localhost...). When a process is sandboxed, it will sometimes need access to things beyond its sandbox (like accessing the filesystem to access a cached image or something). To do so, it will talk to another process over an IPC mechanism, with a well-defined protocol.

[1]: https://tc.gts3.org/cs6265/2019/tut/tut06-01-rop.html


Guessing partly, but maybe ArbR = arbitrary read, ArbW = arbitrary write, RCE = remote code execution, IPC = inter process communication.


ACE arbitrary code execution

RCE remote code execution

ROP return-oriented programming, which I understand to be using code already on the target and manipulating code flow in order to piece together the boots of programme to execute a routine of the attackers choosing (like cutting letters out of a newspaper to make a ransom note!), https://en.m.wikipedia.org/wiki/Return-oriented_programming


because you have to fetch it from RAM, unless the problem is small enough to fit in cache


Ah, right. I don't know how I forgot about cache and RAM.


> because you have to fetch it from RAM, unless the problem is small enough to fit in cache

... might have to...


>But I'm not sure this fallacy has a name.

I've also noticed it, and I've attributed it to the fact that the devil is in the details - you see all the intricacies and problems in the details of the solution you know, but only the shiny facade of the other proposed solution. It's basically the same idea conveyed by "The grass is always greener on the other side of the fence" - that's not a very handy name though.


Yeah, it's partially a grass-is-greener thing, but partially a fundamental failure to realize that you're allergic to grass, and even if the grass really is greener, that won't actually solve your problem.


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

Search: