HNHacker News
TopNewBestAskShowJobs

st_goliath

5,657 karma · joined August 28, 2019

https://infraroot.at/

https://goliath32.com/

https://github.com/AgentD/

https://hn-wrapped.kadoa.com/st_goliath?share

submissionscomments
st_goliath··on SD/MMC cards, a year later (2010)
> I’m looking into using sd cards for my backups.

probably not a good idea. Modern, high density SD cards will likely use not very reliable MLC NAND internally, pretty much requiring active maintenance by the software on the built-in controller.

I once had an embedded board booting from MLC NAND that lost its entire u-boot environment after being without power for a year, just sitting on a shelf in my office.

Similarly, at home, I have an SSD with Windows on it for occasionally playing games. It required extensive recovery after sitting in a desk drawer for a little over a year.

I generally wouldn't really trust flash memory for offline backups.

st_goliath··on Box2D 3.0 Released
Fully agree! Years ago, I attended a course where we basically did just that. (For extra fun: I also attended a parallel computing course at the time, where 90% of our exercises turned out to be heat distribution simulation on a toy cluster. Both courses ended up being back-to-back in adjacent rooms)

Modeling solid or even soft bodies as simple spring-mass-damper systems is surprisingly straight forward and gets impressive results fast. Getting results that are numerically stable, is a bit of a step up from there. IIRC the step up to rigid body simulation was a tough one, but mainly because of the annoying collision detection & handling logic. It's a bonanza of trade offs and everything you do essentially has different classes of issues. Keeping track of both performance and stability is bit of a PITA. I'd guess that's also your main difference between doing just 2D vs 3D, all of the other math should be the exact same.

I remember we did a strange detour into Navier-Stokes equations and 2D fluid simulation towards the end, which I'd argue was a much bigger step up. I ended up the only one with a (very slow but working) solution, having asked a friend with a physics degree for help.

We did some little project assignments at the end where I implemented a simple height map based water surface simulation[1]. Another surprisingly simple little project I recommend trying, that also yields impressive results fast.

I recall another guy who implemented cloth simulation and ran into massive problems with the numeric stability. Turns out, doing straight forward spring-mass-damper systems with Euler integration literally explodes in your face all the time. Multi step Runge-Kutta is of course much more stable, but again, requires a lot of tweaking to get up to reasonable speed.

[1] https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdc08/slides...

st_goliath··on NASA says Boeing Starliner astronauts may fly home on SpaceX in 2025
Sure, that worked just brilliantly over at OceanGate
st_goliath··on SDcard wear leveling and translation layers (2014)
> low cost PIC microcontrollers

ahhh, I think there's the source of our confusion: I suspect you are actually talking about NOR flash?

NOR flash is physically organized different from NAND. It typically does allow single word/byte or sometimes even bit level accesses, like you described. NOR flash is also much more reliable, often not needing any wear leveling at all. The downside is that NOR flash has orders of magnitudes lower data density.

Microcontrollers would use NOR flash internally for program memory, precisely because it allows direct, single-cycle access to individual opcodes. With NAND flash, program memory would have to be read page-wise and require some sort of instruction cache in between. Other EEPROM-like devices (e.g. AT28Fxxx) also use NOR flash for pretty much the same reasons.

On some embedded Linux devices, NOR flash is used for config/boot loader/kernel, while the rootfs lives on NAND.

st_goliath··on SDcard wear leveling and translation layers (2014)
I was talking about bare NAND flash, not eMMC or anything otherwise "fancy" with builtin FTL. What you say is certainly true for those.

None of the projects you describe sound "cheap" or like they involve devices first-and-foremost optimized for cost, and are unlikely to involve such dirt-cheap, raw NAND devices that are becoming increasingly rare even in the super-cheap embedded space.

The original context of the discussion (see: a few comments up) is on-die NAND flash, inside SD cards, which TFA is about.

The flash chips I brought up for comparison were from an extremely cost-optimized, embedded device that I worked on ~2016. The more expensive one already being on the upper end, regarding smarts & cost, but still exposing the flash directly (plus ECC & bad block management, but no FTL).

I mostly work with industrial devices, and also maintain the Linux user space for raw flash (mtd-utils). I have seen my fair share of broken flash devices over the years (often in-field) and also have a my own little pile of broken industrial SD cards on my desk :)

st_goliath··on SDcard wear leveling and translation layers (2014)
> normally with raw nand you use ecc, right?

yes, reasonably priced ones have an internal ECC engine, very cheap ones don't. The Linux NAND framwork has software ECC engines for those (see also: previous discussion on HN[1]).

> was there any ecc happening in your tests?

I deliberately turned it off. Linux has an ioctl for that. If the chip supports it, you can read/write without ECC or even directly into the OOB area where ECC data would normally be stored. The problem with the more expensive MLC NAND was that it had some smarts built in. It could discover overwrite attempts, as well as certain write patterns and apply a scrambling mask to the bits, so that the stored bits would (hopefully) not diffuse over to their neighbors.

> if you started with a page with valid ecc data and then tried to bash an arbitrary payload 1 bit in it to 0, you'd have a real challenge updating the ecc data to be consistent with the updated payload

If you are implementing a raw flash driver, there is a "nandbiterrs" test that does roughly what you describe: it bashes an increasing number of bit errors into a page and reads it back with ECC re-enabled, checking how many errors are successfully corrected during read, before the ECC engine gives up.

[1] https://news.ycombinator.com/item?id=38361139

st_goliath··on SDcard wear leveling and translation layers (2014)
You cannot do single byte writes on NAND. You have erase blocks (typically several 100k to M range) that are divided into pages (typically a few to several dozen k), some devices have sub-pages but that's about it, that's the smallest unit of data you can write.

If you attempt to clear bits from 1 to 0 on an already written page, it will generally not work.

I say generally, because I have actually tried this using raw NAND flash on an embedded Linux device. I found a chip, where it did work, but not very reliably.

I also had an MLC chip, where it did not work, but instead caused random bit-flips on seemingly unrelated pages. I used this trick to systematically hammer down on the pages and figure out the pairings (only document in the NDA version of the datasheet), but failed to reproduce this on a different, more expensive MLC NAND.

But even if appending in this fashion did somehow work, you would still need to update a data structure somewhere else anyway, telling you the exact amount of data written (including cases where you actually append 0xff bytes).

st_goliath··on SDcard wear leveling and translation layers (2014)
Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data.

Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.

st_goliath··on SDcard wear leveling and translation layers (2014)
At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out why they broke.

One of the anecdotes I distinctly recall was about a batch of cards that (for obvious cost saving reasons) used the actual data flash to store its own firmware as well.

IIRC due to a bug in the wear leveling accounting, once the card got sufficiently full, the wear leveling code ended up partially overwriting the firmware itself.

st_goliath··on Eza: A modern, maintained replacement for ls
> which of the letters a to z and A to Z are NOT switches that modify the behavior of ls?

For GNU ls: e/E, j/J, V, K, M, O, P, W, y/Y and z are not used

It uses all the other upper and lower case letters, along with digit 1 and has a hand full of long options without a corresponding short one.

Edit: I double-checked the man page, I'm surprised how many are unused, I would have guessed that it uses all of them by now.

st_goliath··on For advertising, Firefox now collects user data by default
While the Wikimedia Foundation is often quoted as having cancer[1], I guess the Mozilla Foundation has Alzheimer's, constantly forgetting who they are and why they are here in the first place.

[1] https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C...

st_goliath··on It All Started with a nop
The Vivante family of 3D GPUs are available as IP cores, developed by the same named company[1].

Vivante GPUs are used in some ARM SoCs like the NXP i.MX6 and i.MX8.

Etnaviv is the name of the reverse engineered FLOSS Mesa driver. It's support for OpenGL/ES features is sadly lagging quite a bit behind[2].

This article discusses shader compilation and ISA documentation in the Mesa driver using auto-generated code from a high-level, formal specification of the instruction set (in XML), rather than a tons of hand-written C code. A merge request for auto-generated ISA documentation is currently pending [3].

[1] https://en.wikipedia.org/wiki/Vivante_Corporation

[2] https://mesamatrix.net/

[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23...

st_goliath··on Ariane 6 launch: how to watch and what to look out for
> Ariane 6 is scheduled to launch on 9 July 2024, with a launch window from 15:00-19:00 local time at Europe’s Spaceport in French Guiana (19:00–23:00 BST, 9 July 20:00–10 July 00:00 CEST).

Live stream, starting half an hour before liftoff (English audio): https://www.youtube.com/live/B0oFpOJaIYc

st_goliath··on Everything you've been told about the 'Chickenpox bomber' is wrong
I guess this seems to be the current trend in clickbait?

Over the last couple months, I've seen an increasing number of headlines and YouTube videos scroll past that were of similar shapes ("Everything you know/knew/were told/people say about X is wrong", "Why is everybody complaining/so obsessed/claiming Y/... about X?") and every single time it's the first time I hear about X or it's asserted property.

The idea behind it is probably that you feel behind the curve because "everybody" is talking about X and you haven't even heard about it. So you click the link (or on Youtube: the angry-shouty-guys face) to learn about X. Enough people do it, and suddenly, everybody on social media is talking about X, or correcting each other that X actually isn't Y.

st_goliath··on QuickJS, the Next Generation: a mighty JavaScript engine
As the title & link suggest, this project is a fork from QuickJS, a Javascript originally developed by Fabrice Bellard (https://bellard.org/quickjs/).

The fork is apparently in the process of re-integrating with upstream, after work on QuickJS resumed.

From the QuickJS-ng README:

> In October 2023 @bnoordhuis and @saghul decided to fork the QuickJS project

> ...

> As of early 2024 both projects agree the proper path forward involves merging both projects and combining the efforts.

st_goliath··on How GCC and Clang handle statically known undefined behaviour
In the second example, the constant is propagated across expression/statement boundaries. It is likely, that this happened on IR level, rather than on the AST level.

I'd imagine the generic case becomes a non-trivial problem if you don't want to produce fluke/useless diagnostic messages.

The compiler might already be several optimization passes in at this point, variables long since replaced by chained SSA registers, when it suddenly discovers that an IR instructions produces UD. This itself might end up being eliminated in a subsequent pass or entirely depend on a condition you can't statically determine. In the general case, by the point you definitely know, there might not be enough information left to reasonably map this back to a specific point in the input code, or produce useful output why the problem happens here.

st_goliath··on Arm64EC – Build and port apps for native performance on Arm
> ... 16-bit realmode (V86), 16-bit protected mode, and 32-bit protected mode code in the same process by using different segment descriptors...

> ...Intel could've made ARM32/64-mode segments a reality...

While I myself admire this particular breed of masochism, the direction that Intel currently wants to take is apparently quite the opposite.

In May last year, they proposed X86S[1][2][3] which tosses out 16-bit support completely, along with 32 bit kernel mode (i.e. the CPU boots directly into 64 bit mode, 32 bit code is only supported in ring 3).

The proposal trims a lot of historical baggage, including fancy segmentation/TSS shenanigans, privilege rings 1 & 2, I/O port access from ring 3, non-flat memory models, etc... limiting the CPU to 64 bit kernel mode, and 64 or 32 bit x86 user mode. With the requirement for 64 bit kernel mode, it effectively also removes un-paged memory access.

[1] https://en.wikipedia.org/wiki/X86-64#X86S

[2] https://www.intel.com/content/www/us/en/developer/articles/t...

[3] https://news.ycombinator.com/item?id=36006446

st_goliath··on A buffer overflow in the XNU kernel
"imagine feeding this into an LLM/ChatGPT" is the new "imagine a Beowulf cluster of these"
st_goliath··on Let's Destroy C
In summary: someone with a GitHub account discovered that you can hijack the C pre-processor (give or take some GNU language extensions) to transpile BASIC/PASCAL/ALGOL like languages to C. They call their macro collection "evil" and ramble about destroying C, trying to create some form of mystique I guess.

The idea by itself is nothing new and pretty much any novice C programmer eventually stumbles across it. Famously, the original Bourne Shell was written in a variant of ALGOL68, fed through a C compiler using macro based translation[1][2], which helped spark the idea for the IOCCC[2].

[1] https://en.wikipedia.org/wiki/Bourne_shell#History

[2] https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...

st_goliath··on The New 'Dream Chaser' Spacecraft Prepares to Visit the ISS
Well, there already are other, operational space planes besides the X-37B. Namely the Shenlong[1] (3 success full missions) and the CSSHQ[2], the later being currently in orbit (3rd mission, launched in December 2023).

But we don't know that much about those either, as they are kept in just as much secrecy as the X-37B.

[1] https://en.wikipedia.org/wiki/Shenlong_(spacecraft)

[2] https://en.wikipedia.org/wiki/Chinese_reusable_experimental_...

st_goliath··on Let's Embed a Go Program into the Linux Kernel (2023)
I'm a bit surprised the bulk of the comments here seem to fixate onto Go specifically, seemingly missing the actual point of the article:

The article demonstrates the Usermode Driver API, showing how a Linux driver can offload work into userspace (with or without access to a working filesystem).

I mentioned this yesterday in the context of the in-kernel codec discussion[1], where the questions "can't this be done in userspace" or "why not sandboxing" were dismissed pretty quickly.

[1] https://news.ycombinator.com/item?id=40174516#40184307

st_goliath··on Giving Rust a chance for in-kernel codecs
The kernel has API in place to run code in userspace from within a kernel module ("usermode driver"). That would in theory be one way something complex in the kernel could be isolated. The obvious downside being the additional context switches and round trips for the data adding latency.

Here's a blog post that demonstrates embedding an entire Go program as a blob into a kernel module and running it in userspace from the module:

https://www.sigma-star.at/blog/2023/07/embedded-go-prog/

st_goliath··on Xz format inadequate for long-term archiving (2016)
This article is originally from 2016, not from 2022, as has also been pointed out when it was last posted circa 11 hours ago.

2024: https://news.ycombinator.com/item?id=39868810

2022: https://news.ycombinator.com/item?id=32210438

2019: https://news.ycombinator.com/item?id=20103255

2018: https://news.ycombinator.com/item?id=16884832

2016: https://news.ycombinator.com/item?id=12768425

It is utterly unrelated to the ongoing issue (which I'm 100% sure is the reason this is on the front page for a second time within 12 hours right now).

The author is also the developer of lzip, while it does have some valid points, one should apply a necessary level of skepticism ("Competitors product is really bad and unfit", says vendor).

st_goliath··on Running a Raspberry Pi with a read-only root filesystem
Surprisingly, the article doesn't seem to mention SquashFS[1] or EROFS[2].

Both SquashFS and EROFS are filesystem specifically designed for this kind of embedded, read-only use case. The former is optimized for high data density and compression, and already well established. The later is comparatively new and optimized for high read speed.[3] SquashFS as a rootfs can already be found in many embedded applications using flash storage and is typically also combined with tmpfs and persistent storage mount points or overlay mounts.

For both those filesystems, one would build a rootfs image offline. In the Debian ecosystem, there already exists a tool that can bootstrap a Debian image into SquashFS[4].

[1] https://en.wikipedia.org/wiki/SquashFS

[2] https://en.wikipedia.org/wiki/EROFS

[3] https://www.sigma-star.at/blog/2022/07/squashfs-erofs/

[4] https://manpages.debian.org/testing/mmdebstrap/mmdebstrap.1....

st_goliath··on On the Costs of Syscalls (2021)
> ... can change during the lifetime of a process, ...

Fun fact: this is already an issue for the vdso.

gettimeofday(2) can use the CPU builtin cycle counters, but it needs information from the kernel to convert cycles to an actual timestamp (start and scale). This information too can change during the runtime.

To not have userspace trampled over by the kernel, the vdso contains an open-coded spinlock that is used when accessing this information.

I learnt about this while debugging a fun issue with a real-time co-kernel where the userspace thread occasionally ended up deadlocking inside gettimeofday and triggering the watchdog :-)

st_goliath··on Heads up – effectively offline for now
~2 days ago: https://news.ycombinator.com/item?id=38985273
st_goliath··on Two classic radiosity books now free
Basically the idea behind radiosity is, you divide the surfaces in your scene into discrete patches (i.e. tiny rectangles mapped onto everything). A patch receives energy from a light source, or reflected energy from other patches, and it reflects all of that back into the scene (conservation of energy).

The assumption is, that a patch is perfectly diffuse and it reflects in all directions equally. Imagine a fish-eye-lens perspective (actually a hemisphere) from a patch into the world. The projected size and visibility of all the other patches gives you the proportion of energy transferred to/from that other patch.

> Was it a performance matter ...

Computing the final color of a patch is somewhat computationally expensive. It involves either inverting a giant matrix, or iterating until you reach a stable result. The end result is not a rendered image, it's a perspective independent light distribution in your scene. You still need to combine that with another rendering technique, like ray-tracing or rasterization to actually get a picture.

Computer games of the era you mention (e.g. the Half-Life series and other GoldSrc/Source engine based games), did radiosity in an offline, pre-computation step and stored the patch colors in a texture (this is usually called a light map). Using the light map at runtime is pretty cheap.

> ... or was it a physical model limitation (you can't simulate all light phenomenons) ?

As I described above, radiosity assumes perfectly diffuse reflectors. It can't do mirror-like specular reflection of light. Ray-tracing and radiosity actually complement each other really nicely in that aspect, as mirror like reflections are trivial to do with ray-tracing and you can integrate light maps for indirect, diffuse bounces.

That said, with modern hardware, doing radiosity in real-time even for reasonably sized scenes has become feasible. There is e.g. the proprietary "Enlighten" engine that claims to do real-time radiosity. There are other approaches that have become feasible as well, like doing real-time photon mapping. Ray tracing hardware finally being a thing is also certainly a game changer. Well over a decade ago, Crytek did some work on voxel grid diffusion based stuff and Nvidia worked on integrating cone-tracing into that. I have little idea tough what modern game rendering pipelines look like, I've been pretty much out of touch with that industry for quite a while now.

st_goliath··on Two classic radiosity books now free
I have a copy of "Radiosity, A programmers perspective" sitting on my shelf and can recommend it. IMO it does a good job explaining the fundamentals and concepts that Ian Ashdown himself is quoted in the article to have struggled with initially.

It is one of those books, where the author step-by-step pieces together a program and has the explanations structured around that. In this case, it's a radiosity renderer written in C++ called "Helios". At the time of writing, 32 bit Windows was the hot new shit, so the book takes a few detours explaining Windows API and along the way also develops a tiny software rasterizer for visualization.

Sadly, I no longer have the floppy that came with the book and the website (helios32.com) seems to be defunct. It's indexed in the wayback machine tough. The book appears to have been freely available through website for some time already, but I cannot find a snapshot of the source code.

st_goliath··on Chief executive of collapsed crypto fund Hyperverse does not appear to exist
Max Boardroom
st_goliath··on Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
I'm a C programmer with occasional stints in C++, a language that I admittedly have a complicate relation ship with. Personally, I was quite pleased with Qt 5 & Qml when I got to work with it some time back.

I commented on my opinion on Qt/Qml once before: https://news.ycombinator.com/item?id=35652347

I'm mentioning this here because, as already noted in my previous post, HN threads on Qt have this bizarre tendency to attract some really weird FUD/shit-flinging.

Qt is nothing like Electron. It is nowhere near that, or "underperfoming" in comparsion. In my previous post, I even specifically mentioned how the projection I was on was replacing a Chromium + REST backed based stack on an embedded device with Qt, because that was a slow resource hog in comparison. Somehow I have my doubts that comments like that come from actual experience.

← PreviousPage 5 of 15Next →