HN user

return_to_monke

595 karma
Posts31
Comments155
View on HN
algorithmiker.github.io 10mo ago

Faster Argmin on Floats

return_to_monke
22pts11
nnethercote.github.io 2y ago

How to speed up the Rust compiler: data analysis update

return_to_monke
1pts0
www.waterfox.net 3y ago

A New Chapter for Waterfox

return_to_monke
1pts1
fishshell.com 3y ago

Design – fish-shell 3.6.1 documentation

return_to_monke
1pts0
million.dev 3y ago

Virtual DOM: Back in Block

return_to_monke
1pts0
youdontneedamodalwindow.dev 3y ago

Don’t open the details in a modal window, have it be a separate page

return_to_monke
403pts292
www.anthropic.com 3y ago

Claude’s Constitution

return_to_monke
1pts0
github.com 3y ago

Ray tracer written in pure CMake

return_to_monke
2pts1
www.unison-lang.org 3y ago

The Big Idea · Unison

return_to_monke
1pts0
getsol.us 3y ago

A New Voyage – Solus

return_to_monke
3pts0
crablang.org 3y ago

CrabLang

return_to_monke
116pts77
github.com 3y ago

OpenChatKit

return_to_monke
5pts1
www.phoronix.com 3y ago

Linux Kernel Networking Driver Development Impacted by Russian Sanctions

return_to_monke
1pts0
github.com 3y ago

Lambdalisp: A Lisp interpreter written in untyped lambda calculus

return_to_monke
3pts0
pboyd.io 3y ago

The Cargo Cult of Good Code

return_to_monke
1pts0
www.bbc.com 3y ago

Alan MacMasters: How the great online toaster hoax was exposed (2022)

return_to_monke
1pts0
discourse.nixos.org 3y ago

Nix Board Statement – Documentation Team Events

return_to_monke
2pts0
ieeexplore.ieee.org 3y ago

Planting Undetectable Backdoors in Machine Learning Models

return_to_monke
228pts75
github.com 3y ago

A Kernel based root solution for Android

return_to_monke
1pts0
ironicsans.substack.com 3y ago

The Last Calendar You’ll Ever Need – By David Friedman

return_to_monke
4pts1
github.com 3y ago

Open-Assistant

return_to_monke
2pts0
invisv.com 3y ago

Clientless Oblivious DNS

return_to_monke
3pts0
enso.org 3y ago

Enso – Get insights you can rely on. In real time

return_to_monke
2pts0
twitter.com 3y ago

ChatGPT's reasons not to commit suicide, in the style of a pirate

return_to_monke
2pts0
news.ycombinator.com 3y ago

Ask HN: Why didn't dynamically linked dependencies become standard on Android?

return_to_monke
1pts0
onest.md 3y ago

Onest Font

return_to_monke
2pts0
calpaterson.com 3y ago

Firefox usage is down 85% despite Mozilla's top exec pay going up (2020) 400%

return_to_monke
46pts10
www.businessinsider.com 3y ago

Artists: AI Image Generators Can Make Copycat Images in Seconds

return_to_monke
2pts0
github.com 3y ago

Implementation of Dreambooth with Stable Diffusion

return_to_monke
4pts0
gilice.github.io 3y ago

Mid Is Good – Gilice.github.io

return_to_monke
1pts0

The point of markdown is that it is human-readable not only in "rendered" html form, but plain text too.

I think this explains the lack of viewers; they are simply not needed.

You can VACUUM INTO, but standard vacuum won’t rewrite the whole db.

This is not true. From the link you posted:

The VACUUM command works by copying the contents of the database into a temporary database file and then overwriting the original with the contents of the temporary file.

All of these things you mention are "thinking", meaning they require complex algorithms with a bunch of branches and edge cases.

The tasks that GPUs are good at right now - graphics, number crunching, etc - are all very simple algorithms at the core (mostly elementary linear algebra), and the problems are, in most cases, embarassingly parallel.

CPUs are not very good at branching either - see all the effort being put towards getting branch prediction right - but they are way better at it than GPUs. The main appeal of GPGPU programming is, in my opinion, that if you can get the CPU to efficiently divide the larger problem into a lot of small, simple subtasks, you can achieve faster speeds.

You mentioned compilers. See a related example, for reference all the work Daniel Lemire has been doing on SIMD parsing: the algorithms he (co)invented are all highly specialized to the language, and highly nontrivial. Branchless programming requires an entirely different mindset/intuition than "traditional" programming, and I wouldn't expect the average programmer to come up with such novel ideas.

A GPU is a specialized tool that is useful for a particular purpose, not a silver bullet to magically speed up your code. Theree is a reason that we are using it for its current purposes.

There is, it's called flexbox and the CSS grid.

I've found that on simple websites a lot of problems are solved with just a few lines of flexbox config (flex-wrap, etc)

< Continuing on the offtopic thread >

When Eelco wrote his PhD thesis 20+ years ago, with the first version of nix, it was just an academic project. Now it's a lot more.

Although nix has a very good community, and plenty of contributor activity, there is way more code contributed than docs.

Additionally, very few people are technical writers in the nix community (there is a lot of expertise tho, but mostly on the code side). Therefore we get today's nonstructured docs.

Finally, RH has WAY more money than the NixOs foundation. RH sells stuff. Nix and NixOs are community projects, relying solely on donations. They probably have people whose job is to write docs.

there is an ongoing, organized effort to help docs tho: https://discourse.nixos.org/t/fundraising-for-the-nix-docume...

In practice, your best bet is just asking around on community channels (https://nixos.org/community/)

Thunderbird 115 3 years ago

the mock-up has very little information density. I think that would've pissed off a lot of folks, so they reverted it.

I don't think so. there is a lot of hidden complexitxy in flakes.

If you have time, may I ask you to please provide more opinion on what's easier to understand?

We are always looking for more input.

Seems like Slint is trying to be a Flutter but for rust - which is a very nice thing.

Dart has a lot of bad coding concentions taken from Java (eg classes everywhere) which make it really easy to write slow software.