keeperofdakeys

The definition of a pure function is pretty well defined https://en.wikipedia.org/wiki/Pure_function. Math.random depends on hidden state, so (generally) any function using it isn't pure. This doesn't matter much in a language like Javascript, but other languages depend upon this definition (like the lazy function evaluation in Haskell).

So you really have two arguments in there. For pointers, I'm sure no one will disagree that size_t is a good thing. Which is why any modern low-level language has these built-in.

As for fixed size types, what are the alternatives? If you wanted a dynamically sized int, you'd either need to reserve all the possible space you'd need (in which case why not just use a int64_t), or you'd need some kind of heap-allocated integer that can resize itself. We can't hide the fact that the machine itself uses fixed-size ints, unless we are willing to live with a leaky abstraction.

It would be interesting if you adapted this to use the WebStorage api. https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...

From what I understood, Daala was never meant to be a competitor to x265, but a research project that could create a competitor for the next generation, while using no techniques that could questionably come under current patents.

There are actually two animated PNG formats. APNG, a simpler format that was rejected by the PNG working group (supported in Firefox and Safari). And MNG, a more complex format that's an official spec from the PNG working group (formerly supported by Konkerer).

With <video> becoming so widespread, the future for both these formats seems bleak.

There is also a vimscript to turn vimpager into a man pager, which supports basic colouring.

You can probably replace that --no-recursion option on tar, with '\! -type d' on find.

The easiest way to verify file checksums is to use "rsync -c". Rsync will usually skip checksum verification of files if both the modification time and size match on the source and destination, the "-c" option tells it to always compute a checksum.

Sometimes I also use the following "one" liner, if it's local.

    diff <(sort <(cd /path/to/source; \
                  find . -type f -print0 | \
                  xargs -0 sha1sum)) \
         <(sort <(cd /path/to/destination; \
                  find . -type f -print0 | \
                  xargs -0 sha1sum))

Another nice rsync tip is that if you aren't using -a, you should at least use -t (preserve modification time). This will make a second rsync faster as it can skip files if the modification time and size match.

I thought sqlite didn't allow any readers while a write was in progress, but apparently that is no longer the case https://www.sqlite.org/wal.html

There was a period where electrolysis didn't receive much work, and then there was a second push to get it working. That's why it seems to be taking so long.

As for process-per-tab, I can't find anything official about it on the bug tracker. The problem with that option is it leads to quite high memory usage, and hides the existence of memory leaks (chrome really likes to eat my ram). We'll have to see how memory usage goes as they experiment with multiple content processes.

Strangely I can't find it in the latest dev release of chrome or chromium, it's still in stable. At least on linux, it also shows firefox's total memory usage, maybe they are doing lots of comparisons.

Firefox has "about:memory", which can give you some rather detailed information about memory usage.

It could be that it's the other programs that are also bloated.

There has been some thoughts about implementing this for linux, but I don't think it got very far. The idea is that you mark a range of memory as "volatile", and the OS will free that when it's running low on memory. In most cases where you're running out of memory though, swapping out pages or killing a program using the memory is probably the right thing to do though.

https://lwn.net/Articles/522135/

Personally I have both working fine with hundreds of tabs, but chrome uses 5-10 times the ram.

That's good news. I did some searching to find some real comparisons, but most of the links I found were related to memory leaks (nothing from 2016 though, perhaps outdated).

From what I understand, each instance of an electron app essentially needs its own copy of the electron framework to work (which includes a web renderer, and javascript engine). So we're talking at least 50MB per instance, for applications which may have been 10MB if written in a native language. When you start running many applications, it can certainly add up. Users do notice this kind of stuff, they are just too adaptive to bad user experiences.

As for downloads, I remember using dialup and only getting one 1MB file per hour. It would take a lot of patience to even download a 10MB app on that. I don't tend to leave my computer on downloading overnight these days though, and I 'only' get 1MB/s (dslreports.com says I'm "faster download than 60% on DSL in australia").

Personally I think frameworks like Electron lead to huge bloat in terms of download size, disk space, and system ram. However there is no doubt that it increases the accessibility of developing applications for multiple platforms.

I think the following is a great narrative on why it can matter though: http://blog.chriszacharias.com/page-weight-matters

It's also relevant that rust can use multiple direct/indirect dependencies of different versions, due to the way that symbols are exported.

The browser can still access your disk though, so any vulnerability in your browser means arbitrary access. An example from last year https://blog.mozilla.org/security/2015/08/06/firefox-exploit.... That's the reason that I decided to use firejail myself.

A famous example of this was polywater, https://en.wikipedia.org/wiki/Polywater.

For these discount pizza chains, there is usually plenty of coupons floating around - they even accept 'competitor' coupons. You can probably find some if you search for them on the internet.

But as old adage goes, you get what you pay for.

But then you remember that Ed was designed to be used on what essentially was a typewriter, because dialup was so slow, that you couldn't send an entire screen worth of text at once. So you would basically be remembering the text in your head, while inserting and regexing lines.

And the great error handling when it doesn't know what you just told it to do. ?

They'd laugh, because NT already had posix system calls http://social.technet.microsoft.com/wiki/contents/articles/1...

What OP really needs to do is get tcpdump (or similar) output from the vm, and just outside the vm (host or router).

Most languages (including Rust), already support path libraries that abstract this away from you. As long as you use these libraries properly, you should never have these issues.

Here is a great talk by mjg59 about using the TPM, and why it's required https://www.youtube.com/watch?v=rML5DfYUh_k

OWASP can be a good guide https://www.owasp.org/index.php/Top_10_2013-Top_10

Twitter have implemented it, but it's an optional global setting (for now).

Yes sorry, that's correct.