Hacker News: touisteur

New comment by touisteur in "A simplified model of Fil-C"

touisteur — Sat, 18 Apr 2026 06:43:37 +0000

SPARK does static analysis (proof) of Absence of Runtime Errors (AoRTE).

New comment by touisteur in "Python Package Compiler:Package Matlab Programs for Deployment as Python Package"

touisteur — Fri, 17 Apr 2026 11:22:50 +0000

As with all things mathworks, migrating away from simulink to alternatives isn't an easy ride. Just having an alternative to Embedded Coder to generate code in another (safer) language proved just too much years ago...

New comment by touisteur in "My astrophotography in the movie Project Hail Mary"

touisteur — Wed, 25 Mar 2026 14:55:58 +0000

Bright stars are so bright they literally mask areas of the sky. You'll probably need deconvolution algorithms (CLEAN being the standard some time ago, don't know whether some AI/deep-inv approach works nowadays...) to remove them.

New comment by touisteur in "Unlocking 25 Gigabit/S on 10 GbE Direct Attach Copper"

touisteur — Mon, 23 Mar 2026 19:41:55 +0000

Forgot about ONU ! Now I need to look into what an ONU can do, and what one can run on it...

New comment by touisteur in "Unlocking 25 Gigabit/S on 10 GbE Direct Attach Copper"

touisteur — Mon, 23 Mar 2026 12:33:12 +0000

That was a very eye-opening post, full of very interesting details on how modern wired networks work, between NIC and the physical layer... so many mysteries about SFP black magic just falled into place in my head...

New comment by touisteur in "2026 tech layoffs reach 45,000 in March"

touisteur — Sun, 15 Mar 2026 14:31:05 +0000

Some things that Meta shares or opensources is discrete but amazing. lz4 and zstd and Yann Collet's work. io_uring (don't know if Jens Axboe is still there). And the open timecard projects, and overall OCP work.

New comment by touisteur in "The real cost of random I/O"

touisteur — Mon, 02 Mar 2026 12:27:39 +0000

I'm not harping on the usefulness. More like trying to understand what would be the merit or use-case of frequent or permanent monitoring of this. Are there know failure/degradation modes from the storage HW or the filesystem, or database problems that would be detected by running this continuously. Sibling answer talks about SAN, which makes sense. Wondering what the other use-cases are here.

Otherwise, yes, of course,using it as calibration after any HW change would be interesting.

New comment by touisteur in "The real cost of random I/O"

touisteur — Mon, 02 Mar 2026 12:22:07 +0000

Oh thanks. Forgot about this case.

New comment by touisteur in "The real cost of random I/O"

touisteur — Sun, 01 Mar 2026 17:42:54 +0000

Genuinely curious: where would one expect the drive performance to fluctuate? Wear ? Lack of TRIM ? Some form of timely GC process on disk firmware ? Fragmentation or compaction of some sort ? Maybe weird shenanigans with RAID setups with disks from different vendors and batches ?

Embarking right now on a long-term embedded storage project and wondering what people actually monitor (apart from SMART and latency/throughput at app or db-level).

New comment by touisteur in "Show HN: Babyshark – Wireshark made easy (terminal UI for PCAPs)"

touisteur — Tue, 24 Feb 2026 15:38:01 +0000

There's a layer above that, when CLI and bash and sed and tshark are becoming too hairy or slow, and it's 'just' parsing the pcap frames in your language of productivity. Over the years I've built layer over layer of optimized Java code to parse and analyze pcap/pcapng files with either visitor patterns or active iterations (and multi-pass analyses through indexation, or just interfacing with duckdb for months-long-capture analysis to surface low signal-to-noise-ratio events). It builds a good understanding of all the layers and brings the power of a full-featured workbench (language, IDE, libraries, visualization options...).

Built it in Java, and rebuilt it in Ada, and Rust. I find it's a good exercise to learn about a programming language... bonus point, once I have a parser, plugging it live behind libpcap, dpdk, xdp, or just raw sockets is easy.

New comment by touisteur in "BarraCUDA Open-source CUDA compiler targeting AMD GPUs"

touisteur — Thu, 19 Feb 2026 18:08:48 +0000

Aaaaaaand torch is not a simple easy target. You don't just want support but high-performance optimized support on a pretty-complex moving target... maybe better/easier than CUDA but not that much it seems.

New comment by touisteur in "Making geo joins faster with H3 indexes"

touisteur — Sun, 08 Feb 2026 14:57:05 +0000

But what would they use before bringing in postgis ? I'm curious about the alternatives. MongoDB for example doesn't seem to have a geospatial ecosystem, apart from basic 2d features. Clickhouse ?

New comment by touisteur in "Thirty Years of the Square Kilometre Array"

touisteur — Sat, 07 Feb 2026 16:10:53 +0000

BTW if you're interested in the concept of upgrading a sensor without retooling the RF part, and the impact of 'just' putting new COTS racked server hardware and engineering man-hours to get a 'new' sensor with new capabilities, have a look at Julien Plante's work on NenuFAR (which isn't like the SKA at all :-) : https://cnrs.hal.science/USN/obspm-04273804v1 . Damien Gratadour, his PhD supervisor is an amazing technologist, dedicated to improving astronomy instruments, and I was very lucky to work with him and his team... the things the French can string together with small teams and thin budgets...

New comment by touisteur in "France's homegrown open source online office suite"

touisteur — Sat, 07 Feb 2026 15:51:10 +0000

Forking Firefox whenever the rug is pulled seems doable (with elbow grease), and in the meantime Europeans can invest on problems that don't have an already mature fully open-source solution.

New comment by touisteur in "Invention of DNA "page numbers" opens up possibilities for the bioeconomy"

touisteur — Sat, 07 Feb 2026 08:36:31 +0000

I think Bourbaki did brought forth a shift (clean-up) in mathematical notation and writing, at least in France.

New comment by touisteur in "The Book of PF, 4th edition"

touisteur — Sun, 01 Feb 2026 12:02:41 +0000

Not to ask anyone for free work but any write-up on this, I'd love to read.

New comment by touisteur in "Thirty Years of the Square Kilometre Array"

touisteur — Thu, 29 Jan 2026 00:13:14 +0000

Remembering now that SKA is many, many things and I was talking of the higher-bands array still being installed, but many infos on the -low and -mid arrays are available, for example https://www.skao.int/sites/default/files/documents/Year_In_T...

New comment by touisteur in "Thirty Years of the Square Kilometre Array"

touisteur — Thu, 29 Jan 2026 00:04:29 +0000

Sorry, not sure I follow from what I said (explaining how much data sensors produce) to 'increasing the sampling frequency' ? You're usually sampling at larger width to then put specifically taylored pass-band filter and removing aliasing effects and then downsampling. This is a classic signal acquisition pattern : https://dsp.stackexchange.com/questions/63359/obtain-i-q-com...

New comment by touisteur in "Thirty Years of the Square Kilometre Array"

touisteur — Wed, 28 Jan 2026 17:54:21 +0000

I think they preserve timestamped I,Q data. Know some people looking at down-sampling, preselecting those signals for longer term storage and deeper reprocessing and they seem to have a 24h window to 'analyze and keep what you need'.

We're still in technological phase where ADCs are far more advanced than storage and online processing systems, which means throwing away a lot. But I have high hopes for a system where you upgrade computing, network, storage (and maybe ADCs...) and you get an improved sensor. Throw man-hours at some GPU kernel developers and you get new science. The limit seems more now about enough people and compute to fully exploit the data than technological...

New comment by touisteur in "Thirty Years of the Square Kilometre Array"

touisteur — Wed, 28 Jan 2026 14:16:52 +0000

On SKA from what I understand they're sampling broadband but quickly beamform and downsample as the datarates would be unsustainable to store over the whole array.