Some things I've learned about memory
neugierig.org
neugierig.org
Who's that? Feels to me like he or she is due some credit.
URL : http://www.selenic.com/smem/
First changelog entry is by "Matt Mackall":
Is anyone here able to guess (or even state as fact) what this blog is based on? I'm trying to get into blogging for a long time and this is the cleanest and (by _far_, being used to Europe's internet speed I'm often cringing here) fastest site I've seen on HN for a long time. What's the secret sauce, if the author isn't just creating static html files manually..?
He probably has some basic (selfmade?) constructs like templating systems, and the front page could possibly be maintained by a simple cron script that looks for entries.
If you look at the source, it is exceedingly simple. The linked article, for example, is: 25 lines of header, text body, and a call to Google's Urchin.
The other guesses are correct. The code is here, but it's undocumented and specific to the site. https://github.com/martine/cms
It's pretty straightforward to write your own such thing (though you must be careful about the details when generating a feed) or use one of the many other static site generators like Jekyll.
EDIT: evmar answered the question before I posted my reply. That's what I get for keeping HN stories open in tabs.
Bear in mind that there are many ways that memory can be used, including (in the case of some applications) specialized memory allocators that look after memory within a process. For example SLAB allocation etc.
The obvious thought is: We need to create more addressable space to take advantage of this plentiful physical memory.
The less obvious thought is: Given that we have such plentiful physical memory, why are we using an old hack that was designed for a problem that no longer exists?[1] The name of the problem: Not enough physical memory to keep processes in their own space. The name of the hack: Shared memory and dynamic linking.
1. Of course, we can keep making software larger and more resource intensive to perpetuate the problem and thus justify the ongoing use of the solution (shared memory). A comparative example might be disk space. We have so much disk space that we can keep making files larger (e.g. programs, operating systems, document/media files, data collection) to justify a need for more space.
Commence downvoting.
I do agree that we may be ready to have something cleaner than the old shared library model. Just don't suggest it was a one trick pony.