News for hackers. Stuff that matters.

nuopnu

There are vram disks, so at least you can use it for the swap.
Re:Full Moon: Seestar S50 vs. Samsung S25 on Friday September 12, 2025 @03:19AM (#45219540)
Yes, but it's irrelevant here.
Re:Full Moon: Seestar S50 vs. Samsung S25 on Friday September 12, 2025 @03:18AM (#45219535)
They do, but not in Pro mode: (S23U) https://ibb.co/B2hN7jwZ
Re:Entire website in a single HTML file on Friday December 24, 2021 @01:09AM (#29670805)
Just embed both CSS files and images in the HTML file.
A "better offline music on the iPhone".
Re:Apple Dylan IDE (2014) on Sunday June 04, 2017 @03:47AM (#14480327)
You are thinking of a structured editor.

But as to the single feature you mentioned, see for example Code Bubbles:

https://www.youtube.com/watch?v=PsPX0nElJ0k

Re:Unicode is hard on Monday May 29, 2017 @11:31AM (#14439571)
A rocket can take you to the Moon. Is it easy to operate? Or to learn how to? To maintain it and prepare on the ground?

Not just it would be harder, but you couldn't get into space without it at all, so that got comparatively easier.

Is it still all easy, though?

Re:Unicode is hard on Monday May 29, 2017 @10:31AM (#14439258)
But comparing something to something else and it being easy, doesn't make it easy by itself.

Paraphrasing the joke about new standards: we had a problem, so we created a beatiful abstraction. Now we have more problems. One of the new problem being normalization.

It doesn't undermine the good that Unicode brought, but you can't say to have included some unilib.h and use its functions without understanding all the Unicode quirks and its encodings, because some of the parameters wouldn't even make sense to you, like the same normalization forms.

Re:Unicode is hard on Monday May 29, 2017 @09:47AM (#14439061)
It is actually hard.

https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/

But one's sticking with only some part of Unicode support that they understand/need is easy, sure.

Re:How to Build a Non-Volatile Memory DBMS on Monday May 22, 2017 @02:28PM (#14395836)
Practically it's even less than 47 bits. :) But sure, know your limits.
Re:How to Build a Non-Volatile Memory DBMS on Monday May 22, 2017 @10:23AM (#14393766)
Not exactly. I'm not a user of this, but

http://www.lmdb.tech/doc/group__mdb__env.html#ga492952277c48...

Ctrl+f through the doc for "MDB_FIXEDMAP" for more details.

So there is _some_ support, where you can expect to have the whole file at a fixed address. What is not handled is that your data may be moved within the file, and there's nothing you can do about it, short of keeping a long-lived read only transaction:

http://www.lmdb.tech/doc/todo.html

Re:How to Build a Non-Volatile Memory DBMS on Monday May 22, 2017 @04:49AM (#14391991)
The presentation and the paper pretty much describe how LMDB works already.

https://symas.com/lightning-memory-mapped-database/

Except, it allows only a single writer and it's not directly byte-addressable, unless you make a request to preallocate a chunk of fixed-size mmap'ed memory.

Re:NixOS 16.03 Released on Saturday April 02, 2016 @08:42AM (#11411311)
I can't provide you a full solution, but here are the hints:

- gcc5 definition: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

- Old cc wrapper with a custom libc option https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

- libc in the GCC package itself: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...

The whole system is very modular and customizable. But yeah, very hackish and undocumented.