When I started debugging this issue, I had no idea how far down the rabbithole would go!

A few months ago, I was writing an end-to-end test for the Nextcloud integration with OnlyOffice under NixOS, to be run in a QEMU virtual machine. Curiously, my test suffered from corrupt reads from a host folder that was mounted into the VM. That was the start of a journey that led me deep into the Linux Kernel.

The circumstances under which the problem occured were very specific: a certain file, read from a host folder that was mounted into the VM, would consistently be corrupt. Specifically, this was a 12943-byte file, which inside of the VM would also be 12943 bytes, but only the first 0x3000 bytes were populated: the rest was filled with zeroes. At this point I was convinced it likely only affected a very limited set of users – but I was determined to get to the bottom of it.

Plan9

Mounting a directory from the host filesystem into a QEMU VM typically happens by passing something like -virtfs local,path=/nix/store to the qemu startup command. This tells QEMU to start a small server exposing the Plan 9 filesystem protocol (P9). The kernel ‘inside’ the VM can then use the 9P_FS kernel module to mount the directory over this protocol.

Adding some tracing options to QEMU:

virtualisation.qemu.options = [
  "-trace 'v9fs*'"
];

… I could observe that, whenever I read the file, this read would be split over two v9fs_read calls: one of 0x3000 bytes, and one of 655. The data from the second call was somehow ‘going missing’. Was the QEMU server serving an empty block, or was P9_FS inside the VM dropping them?
Patching for diagnostics

To get more insight into what was going on on the Linux Kernel side, I configured the system-under-test to log the first byte of each read:

boot.kernelPatches = [ {
  name = "enable p9 debugging";
  patch = ./kernel-rread.patch;
  extraConfig = ''
    NET_9P_DEBUG y
  '';
} ];

boot.extraModprobeConfig = ''
  # ERROR+9P+VFS+CACHE=1+4+8+8192=8205
  options 9pnet debug=8205
'';

--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -1599,7 +1599,7 @@ p9_client_read_once(struct p9_fid *fid, u64 offset, struct iov_iter *to,
    return 0;
  }
  
+ p9_debug(P9_DEBUG_9P, "<<< RREAD count %u, %02x\n", received, *dataptr);
  
  if (non_zc) {
    int n = copy_to_iter(dataptr, received, to);

Sure enough, I saw the 2 RREAD calls on the linux kernel logs as well, and the expected character showed up at the start of the second read.

Reading the code

Poring over the kernel source code, one thing that stood out was that the 9p client would use ‘zerocopy’ APIs for regular reads, but not for small requests:

/* Don't bother zerocopy for small IO (< 1024) */
if (clnt->trans_mod->zc_request && rsize > 1024) {
  /* response header len is 11
   * PDU Header(7) + IO Size (4)
   */
  req = p9_client_zc_rpc(clnt, P9_TREAD, to, NULL, rsize,
0, 11, "dqd", fid->fid,
offset, rsize);
} else {
  non_zc = true;
  req = p9_client_rpc(clnt, P9_TREAD, "dqd", fid->fid, offset,
rsize);
}

Sure enough, the initial 0x3000 read would be a ‘zerocopy’ read, while the second 655-byte read would be small enough to use a ‘regular’ read. Perhaps these APIs were incompatible? It didn’t seem that way – but some experiments with patches did confirm that always using zerocopy made the problem go away. It was clear that I wasn’t going to get closer to the root cause without better visibility into what was actually going on.

Would it be able to attach a debugger to the running kernel?

It seemed plausible: QEMU has facilities for attaching gdb, and sure enough I could:

virtualisation.qemu.options = [
  "-trace 'v9fs*'"
  # open gdbserver on TCP port 1234
  "-s"
];

While gdb successfully attached, it was… pretty much useless, since the running kernel was the compressed bzImage that does not include any debugging symbols. After some digging I found out Nix also ships a vmlinux that does have debugging symbols in the kernel.dev output – promising, but even with that I saw nothing but gibberish.

WHY2025

With this challenge top-of-mind I joined the Dutch hacker camp WHY2025, a great place to meet interesting people. I camped out at the Nix village:

There I bumped into Raito who pointed me to a thread on the kernel ‘regressions’ mailinglist where several people were running into a suspiciously-similar problem.
Debugging Symbols

Encouraged by the fact that the impact might be wider than I originally thought, I continued figuring out how to attach a debugger to the guest kernel. One obvious-in-hindsight piece of the puzzle was that I had to disable kernel Address Space Layout Randomization:

boot.kernelParams = [
  "nokaslr"
];

With that, I could set breakpoints and see reasonable backtraces!

Sadly, I could still not set breakpoints in 9p methods. Something extra was needed to support debugging code that’s in a kernel module – it turns out, a considerable side quest.

Module Debugging Symbols

While the command-line interface to gdb may look simple, looks can be deceiving: it’s a powerful tool. It even supports a plug-in architecture, and the Linux kernel comes with a gdb plugin for loading symbols for kernel modules written in Python.

This did require avoiding stripping the modules:

boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux.overrideAttrs(a: {
  dontStrip = true;
}));

Also, part of the gdb plugin code is generated during the kernel build process, but the Nix packaging of the Linux kernel didn’t expose this yet. I patched the packaging to make this part of the dev output:

--- a/pkgs/os-specific/linux/kernel/manual-config.nix
+++ b/pkgs/os-specific/linux/kernel/manual-config.nix
@@ -325,6 +325,7 @@ lib.makeOverridable (
  "KBUILD_BUILD_VERSION=1-NixOS"
  kernelConf.target
  "vmlinux" # for "perf" and things like that
+ "scripts_gdb"
  ]
  ++ optional isModular "modules"
  ++ optionals buildDTBs [
@@ -432,6 +433,10 @@ lib.makeOverridable (
  postInstall = optionalString isModular ''
  mkdir -p $dev
  cp vmlinux $dev/
+
+ mkdir -p $dev/lib/modules/${modDirVersion}/build/scripts
+ cp -rL ../scripts/gdb/ $dev/lib/modules/${modDirVersion}/build/scripts
+
  if [ -z "''${dontStrip-}" ]; then
    installFlagsArray+=("INSTALL_MOD_STRIP=1")
  fi

Combined with just the right version of the Linux kernel sources (courtesy of pkgs.srcOnly), I could now fully debug the running kernel, including setting breakpoints and inspecting the local variables inside kernel modules.

Folio memory pages

Armed with this looking glass into the running kernel, I could now further inspect the (zerocopy and regular) calls dealing with the data read from the 9P protocol into the user buffers. With the help of some great articles on LWN I deciphered how the data was stored as a folio (basically, a structure of multiple memory regions that together form one ’logical’ region) with iov_iter structures pointing into those pages and coordinating operations on them.

Especially interesting was the observation that, after the first read, the folio was exactly 0x3000 (actually: three pages of 0x1000) in size. When the second p9 read happened, the folio would be ‘grown’ to make room for the additional 655 bytes and then the new data would be copied into it.

However, iov_iter is basically a ‘cursor’ into the folio. When the folio is exactly three 0x1000 segments, and the cursor is ‘at 0x3000’, where do you put it? There is no ‘fourth segment’ that you can put it on the beginning of, so apparently it is placed in the third segment, one byte past its last one. This is what confused the subsequent non-zerocopy read – and led to the problem of the bytes going ‘missing’.

Bringing in the big guns

With the problem pinned down like this, I felt comfortable sharing my findings on the regressions list. What’s more, I could share not only my description of the situation, but an actually-working Nix configuration demonstrating it. With that, 9P_FS maintainer Dominique Martinet could reproduce the issue within hours

this is a huge leap forward (hopeful it’s the same problem and we don’t have two similar issues lurking here…), we can’t thank you enough.

… and when I woke up to a beautiful sunny WHY2025 morning I found his preliminary patch in my inbox:

So that wasn’t a 9p bug, I’m not sure if I should be happy or not?

I’ve sent “proper-ish” patches at [1]

It’s taken some more reviews and iterations, but the fix is now making its way into various kernel releases.

Conclusion

What looked like a bug in an obscure corner of QEMU turned out to be a bug in the Linux Kernel Memory subsystem that, had we not found it, may have caused countless hard-to-diagnose issues in the future.

Big thanks to the NGI Fediversity programme, that saw the value of putting time into this lower-level issue and allowed me to dedicate part of the Source-based Nextcloud and OnlyOffice budget towards figuring this out – otherwise I might not have been able to justify the effort.

A lot of the work went into figuring out how exactly to put the various tools together to achieve the right diagnostic environment. With the scripts_gdb patch now merged and the required configuration documented as a working NixOS configuration, this should easy to set up from now on!

This article also appeared on my personal blog at https://arnout.engelen.eu/blog/linux-kernel-adventure/

Afgelopen vrijdag heeft Virtugon een presentatie gehouden over de automatisering van hoogspanningsstations. De lounge was goed gevuld met een geïnteresseerd publiek.

Na een algemene introductie van het hoogspanningsnet en de componenten op een onderstation vertelde hij over oude en nieuwe stationsautomatisering, netbeveiliging en welke protocollen er in moderne stations gebruikt worden. Hij sloot af met een beeld over de rol van cybersecurity in de operationele technologie en wat er mis kan gaan.

Uit de reacties van de aanwezigen bleek dat de presentatie goed was ontvangen, en dat vraagt om meer! Heb jij ook een awesome onderwerp waar je een echt nerd op bent, aarzel niet en maak een activiteit aan op de wiki voor een lezing of workshop.
Als je dit wel wil maar je vindt het lastig, dan zijn er genoeg mensen die je willen helpen om dit te organiseren.

Al sinds 1989 wordt in Nederland iedere 4 jaar een grote hackersbijeenkomst georganiseerd, sinds de tweede editie in de vorm van een meerdaags kampeerevenement. Iedere editie vindt het evenement zichzelf opnieuw uit, inclusief nieuwe naam. HAR2009 gaf de start aan de eerste Nederlandse hackerspaces, waaronder Hack42. De nieuwste editie, WHY2025, was een paar weken geleden een groot succes – en Hack42 was weer goed vertegenwoordigd.

Zo kwamen de huisstijl en vlaggen onder andere van de hand van Janneke, was Moem actief voor team Deco, en heeft Malou onder meer de banners voor de party- en karaokebar, doorzichtige bekers, en de ‘mate market’-bordjes gemaakt en met Denz bars bemensd. Cat was actief in de keuken van Heaven, Jos zat in de programmacommissie en hp197 in PL. Ad en raboof hebben de social media, online en offline informatievoorziening onder handen genomen. Mack en Bix zorgden in Productiehuis voor de audio- en videotechniek, zowel ‘live’ als voor de opnames die weer snel op https://media.ccc.de/c/WHY2025 beschikbaar kwamen.

In de aanloop naar het evenement hebben we een van de orga-meet gehost, en ook waren we goed vertegenwoordigd in het programma: Stitch, Bix, Maja, Nino, BugBlue, Cyb0rg42 en raboof gaven een talk – soms zelfs meerdere!

Het was weer super hoe deelnemers uit de Nederlandse en internationale community allemaal hun unieke persoonlijke bijdrage leverden om er een veelkleurig evenement van te maken.

Dinsdagavond heeft Squirl een training gegeven over 3D-ontwerpen en -tekenen. Na een introductie over de verschillende ontwerpconcepten werd duidelijk dat de manier waarop je denkt bepaald hoe je tekent. Dit werd gevolg door een vergelijking van opensource en commerciële tekenpakketten waarna hij in SolidWorks aan de slag ging met een live demonstratie van iets dat uit de zaal werd geroepen. Ook liet ‘ie een awesome voorbeeld zien van een volledige C&C machine met alle individuele onderdelen. De avond werd afgesloten met het namaken van een tekening die een van de deelnemers in OpenSCAD had gemaakt.

De deelnemers stelden veel vragen en gingen met een hoofd vol informatie en inspiratie de rest van de avond tegemoet.

Heb je dit gemist? Er worden meer lezingen, workshops en trainingen georganiseerd over diverse onderwerpen, check de agenda voor meer informatie. En als je zelf je kennis wil delen, voel je vrij om een activiteit zelf in te plannen.

Binnen de hackerspaces zijn we (meestal) wel bekend met de drank Club Mate. Dit is Maté met toevoegingen. Squirl was nieuwsgierig naar de OG-maté en heeft daarom op 14 juni een proeverij georganiseerd.

Op deze heerlijk zomerse dag kwamen een aantal mensen samen om warme dranken te consumeren. Een aantal deelnemers hadden verschillende matésoorten meegenomen. We hebben een aantal interessante smaaksensaties ervaren, van standaard fabrieksmaté, tot een sterk gerookte variant geïmporteerd uit Brazilië.

Met het geluid van slurpende bombilla’s kwam de proeverij tot een eind en stuiterden de mensen de rest van de dag in.

Had je hier ook bij willen zijn? We organiseren regelmatig activiteiten en iedereen is welkom, ook als je (nog) geen deelnemer bent. Check onze agenda.

Twee weken geleden vond Hackerhotel plaats, waar ook een talk werd gegeven door Niels Hatzmann en Roman Kniaziev.

Voor wie het nog niet weet, Niels is al bijna drie jaar actief met het leveren van goederenhulp aan Oekraïne. Hiervoor is inmiddels de stichting Aid to Ukraine opgericht, die ook ANBI-status heeft.

Tijdens de talk waren Niels en Roman in gesprek over de situatie in Oekraïne en wat de samenwerkende stichting ETOC (in Oekraïne) heeft kunnen bereiken, mede dankzij de inzet van de vrijwilligers van de stichting Aid to Ukraine.

Je kunt de volledige talk terugkijken via media.ccc.de.

Aid to Ukraine doet alles op basis van vrijwilligers, net zoals veel andere stichtingen binnen de hackergemeenschap zich inzetten voor doelen die zij belangrijk (of leuk) vinden. Sommige van deze vrijwilligers hebben eigen bedrijven waar vanuit zij helpen of zorgen dat hun werkgever meedoet. Sommigen organiseren goederen, anderen repareren deze, en weer anderen brengen de hulp daadwerkelijk fysiek naar Oekraïne.

Het voelt soms alsof deze hulp heel klein is en niet voldoende helpt, maar mede dankzij deze hulp heeft ETOC al 20.000 mensen kunnen evacueren en zijn er ook vele levens gered met de medische hulpgoederen.

Waarom schrijf ik nu dit bericht? Heel simpel: de stichting heeft nog steeds hulp nodig. Ook van jou.

Er is nog steeds behoefte aan Landrovers, traumazorg, en technische middelen voor communicatie en stroomvoorziening. Misschien heb jij thuis nog een ongebruikte laptop, tablet, of netwerkapparatuur liggen? Of misschien heeft je bedrijf/werkgever spullen staan die je kunt doneren? Of heeft je partner/familielid misschien een netwerk wat hulp kan bieden?

Ook gereedschap is welkom, aangezien er in een oorlogsgebied veel spullen gerepareerd of gebouwd moeten worden. Denk aan klein handgereedschap, maar ook 3D-printers en filamenten.

En als je niets fysieks kunt bijdragen, dan is er nog de mogelijkheid om financieel te helpen.

Want ondanks dat er heel veel op vrijwillige basis gebeurt, kost sommige van de hulp die geleverd wordt wel geld. De Landrovers moeten worden aangekocht, of er is een onderdeel voor nodig, de traumazorg spullen komen niet net als de drone-aanvallen uit de lucht, en als er om andere specifieke goederen gevraagd wordt, dan zit er soms niets anders op dan die in te kopen.

De stichting heeft een ANBI-status, dus je giften zijn fiscaal aftrekbaar.

Ben je nu nog aan het meelezen, hartelijk dank daarvoor!

Op zaterdag 8 maart wordt er bij Hack42 vanaf 12:00 uur een reparatiedag gehouden voor technische apparatuur die naar Oekraïne gaat. Wil je een donatie doen, dan kun je die dag langskomen om je spullen af te leveren. Heb je eerst vragen of kun je die dag niet, neem dan gerust contact op. 

Wil je geld doneren? Dat kan via de QR-code op de website van Aid to Ukraine.

En als je toch nog steeds twijfelt over dit alles, dan wil je misschien dit interview nog lezen “Niets doen was geen optie”.

Afgelopen zaterdag (15 februari), was er weer een klusdag in de hackerspace. Nu is natuurlijk iedere dag wel klusdag, maar deze dag was er ook echt een plan. Een team van 9 hackers ging aan de slag met grote en kleine klussen en al snel ontstond er een kakofonie van werkgeluiden, stof en geklets.

Na lang nadenken en plannen zijn er onder andere een tijdelijke opslag gemaakt voor balen steenwol, is er een whiteboard opgehangen, grofvuil klaargezet om weggebracht te worden, de kassa gesloopt en een groot project mbt koffie, maar dat blijft nog even een verrassing.

Het was naast een productieve dag vooral ook een gezellige dag, eentje die voor enkelen doorging tot de eerste uren van de volgende ochtend.

Hack42 is geen gebruiksproduct maar een gemeenschapsruimte. Alle deelnemers kunnen bijdragen aan het veranderen en verbeteren ervan. Alleen zo blijft Hack42 groeien en evolueren. Wat wordt jouw volgende project?

17 januari hadden Dakota en Cat een one-off georganiseerd van een tabletop role-playing game (TTRPG) met het systeem CY_BORG. De naam doet al vermoeden dat het om een cyberpunk thema gaat. Met 7 spelers betraden we onder zorgvuldige begeleiding van Dakota de dungeon master een nieuwe wereld. Nadat we allemaal zorgvuldig een karakter bij elkaar hadden gerold ging de actie van start. Na een net iets te lange periode waarin we allerlei intel verzamelden om een heist in goede banen te leiden ging de actie van start. Maar wie cyberpunk zegt, zegt “live fast, die young”; en dat is ook precies wat er gebeurde. Want ondanks ons geniaal opgezette plan, liep het niet zoals we hoopten en werden we gedecimeerd door de overbewapende en overbepantserde security forces.

Ondanks dat al onze karakters dood of in de gevangenis eindigden was het een zeer gezellige avond, en was deze one-off een goede inkijk in het systeem en de wereld. Het smaakte voor een aantal deelnemers naar meer, dus wie weet hebben we binnenkort een doorlopende campagne op vaste tijden in de space.

Nieuwsgierig geworden? Hou de agenda in de gaten voor een eventuele campagne!

Nieuw tshirt in de shop. WAUW!!1! Koop nu!!!!!

Geef Geld. Consumeer

https://shop.hack42.nl/kleding/shirts/moeshirt

https://shop.hack42.nl/kleding/shirtsFitted/moefittedshirt

https://shop.hack42.nl/kleding/picknmix < als ruglogo

De HOI, Hack42’s Extra Corporate Event: de Hack42’s Officiële Introductie.

Voor iedereen die Hack42 beter wil leren kennen, gaan we weer een nieuwe HOI inplannen.
Je bent recent aangesloten bij Hack42, of van plan dat binnenkort te doen. Je hebt vast al veel op onze wiki gelezen, en rondgedwaald door de space zelf. Toch denken we dat we jou nog net even wat beter wegwijs kunnen maken in onze space. Die kans grijpen we nu graag aan.
Daarom organiseren wij voor jou de “HOI”!

We zullen in ieder geval wat aandacht besteden aan onze communicatie-kanalen, de wiki, space-gebruik, tool-gebruik, de bar, projecten, activiteiten, en vooral: jouw vragen!
Zit je ergens mee, of vraag je je iets af, dan is de HOI hèt geschikte moment om aan te sluiten. (Natuurlijk mag je ook al nu direct je vraag aan ons stellen, zoals altijd)
En heb je nog geen (kluis/voordeur-)sleutel ontvangen, dan zullen we er die avond voor zorgen genoeg op voorraad te hebben.

Meer informatie en een linkje naar de datumprikker vind je hier: https://hack42.nl/wiki/HOI_2024Q4

Op 21 September, Software Freedom Day, verwelkomden we de Nederlandse Nix Meetup bij Hack42: rond de 20 geïnteresseerden, zowel bekende gezichten uit de community als nieuwe

Het formele programma bestond uit een presentatie van raboof over hoe Nix mooi samengaat met software freedom, en van Adriel Matei over zijn framework om een neovim-configuratie te genereren vanuit Nix.

Na de presentaties bleef het nog lang gezellig, en zijn er al allerlei plannen gesmeed voor de volgende meetup. We kijken ernaar uit!

In een vorig blog hebben we een seriële aansluiting gesoldeerd aan een WiFi-router om het boot-proces te kunnen volgen en beinvloeden. Het uiteindelijke doel is Liminix te installeren op deze router. Gelukkig is deze router al goed ondersteund onder OpenWRT, dus dat is een mooi beginpunt.

OpenWRT-upgrade

Liminix is qua kernel gebaseerd op OpenWRT. Helaas zat Liminix nog op een oude OpenWRT-snapshot met Linux 5.15.71, waaronder deze router nog niet goed ondersteund wordt. Daarom hebben we eerst de OpenWRT in Liminix geupdate naar v23.05.2 met kernel 5.15.137.

Image-configuratie in Liminix

Een device in Liminix wordt gedefineerd in “devices/<devicenaam>/default.nix”. We introduceren dus een “devices/tp-archer-ax23/default.nix“, grotendeels gebaseerd op een bestaand device. We gebruiken hierbij de OpenWRT-documentatie om de architectuur, geheugen-offsets e.d. goed te kiezen, en de OpenWRT-code om een kernel-configuratie te genereren.

Booten met TFTP

De image-configuratie is een boel trial-and-error, waarbij de seriële terminal die we vorige keer hebben aangesloten onmisbaar was: via die weg kun je de U-Boot terminal benaderen.

Met Liminix kun je de tftpboot-output bouwen, die bestaat uit een image, een Device Tree (dtb), en instructies hoe je image en dtb naar het geheugen van het device kunt kopiëren en starten. De dtb wordt daarbij zo aangepast dat tijdens het bootproces het stuk van het geheugen waar het image zelf staat netjes wordt vermeden.

Het was nogal verwarrend dat de Liminix-instructies een bootm-commando met 3 parameters opleverde: het locatie van het image, de locatie van de ramdisk (if any), en de locatie van de FTD/dtb.

Helaas heeft the AX23 nog een oudere U-Boot versie, waarbij het bootm-commando nog maar 2 parameters krijgt. Dit betekent dat de dtb niet op de bootm-commandline kan worden meegegeven, maar aan het image moet worden geplakt. Daarvoor kan de tftpboot-module van Liminix iets worden aangepast.

TP-Link safeloader image

Nu we een image kunnen maken dat via TFTP netjes boot, werd het tijd een image te maken dat permanenter op de machine geflashed kan worden. Blijkbaar heeft TP-Link de U-Boot zo aangepast dat deze werkt met hun eigen ‘safeloader’-imageformaat. Als ik het goed begrijp hebben ze met dit formaat wat safeguards toegevoegd zodat je niet meer zomaar een image kunt uploaden dat voor een ander device bedoeld is. Gelukkig zat er in de OpenWRT firmware-utils al een tplink-safeloader tool waarvoor we een Liminix-module hebben toegevoegd.

Inrichting als repeater

Het mooie van Liminix is dat je de configuratie van je device in een soort configuratiebestand kunt beschrijven, en dan een image genereren.

Het configuratiebestand dat ik gebruik vind je hier. Omdat ik de router als WiFi-extender wilde inzetten, is het relatief eenvoudig: een ‘bridge’ om zowel de LAN-poorten als de WLAN-poorten, een DHCP-client om de router van een IP-adres te voorzien, en hostapd-configuratie voor beide WLAN-interfaces. Dit werkte vrij vlot, maar haalde teleurstellende snelheden. Nadat ik de hostapd-configuratie van OpenWRT heb overgenomen ging het wel snel. Ik heb geen bijzonder snelle internetverbinding, maar het is wel leuk dat WiFi nu ook op kantoor niet meer de bottleneck is in de verbinding met het internet:

Volgende stappen

Voorlopig ben ik tevreden met het resultaat.

De meeste verbeteringen hebben we als PR aangeboden aan Liminix en zijn ondertussen geaccepteerd. Alleen de support voor U-Boot mboot prompts met maar 2 parameters zou eigenlijk nog een keer opgeschoond moeten worden zodat die ook kan worden aangeboden.

Wel moet ik nog steeds met ethernet-kabels aan de slag om nieuwe images te flashen. Het zou mooi zijn over het netwerk te kunnen updaten. Liminix heeft daar wel modules voor, daar moet ik me nog verder in verdiepen.

De traditionele post-opendag-linzensoep staat al klaar voor morgen. Hij mag nu nog even wat extra-lekkerder worden, maar moet tot die tijd wel koel staan. De 22 liter pas niet echt lekker in de koelkast. Dus we kiezen voor airco-gekoelde soep…

Tijdelijke actie! Reageer snel!

We hebben nu voor korte tijd een flexplek beschikbaar tegen zeer scherpe tarieven!

#belvoordevoorwaarden

(In relevant nieuws: we hebben een zeecontainer leeg 🥳)

Afgelopen dinsdag hebben we de eerste Taco Tuesday gehad. Er zijn taco’s gemaakt en die hebben we met een aantal Hack42 deelnemers en zelfs een gast opgegeten. Daarna was er zelfs nog gezorgd voor dubbelvla als toetje 😀

Tijdens het eten bloeide het idee van weer vaker samen in de space eten op en werden er al voorzichtig plannen gemaakt voor Nasi, Lasagne en andere lekkere gerechten. Kom er dus gezellig bij, de volgende keer!

Het maken van de taco’s ging goed in de keuken van Hack42.

Het resultaat was lekker 😋

#DinsdagGehaktDag

We hebben iets nieuws in het assortiment 🥳 Omdat overal tegenwoordig glazuur op moet, kunnen wij als hackers nu niet achterblijven…

Maar noemen we het nou de Club-pouce of de Tom-mate???

Sinds kort zijn we ook op 🔵 Bluesky te vinden 🥳 … skeet je met ons mee? #sharelikeandsubscribe

Als je nog geen invite code hebt weten te bemachtigen, kan je ons ook op een van onze andere Socials volgen:

🐘Mastodon

🐦Twitter

🔵Bluesky

👔Linkedin

🕵️‍♂️Facebook

📸Instagram

En als dat niet voldoende is, staat er nóg meer op onze contactpagina.

Weekend van de Wetenschap 2023

Image 1 of 24

Wauw, vandaag was zo cool bij Hack42! Het voelde een beetje als de eerste schooldag, superzenuwachtig enzo. In het begin zag ik allemaal te gekke projecten. Echt, ik wist niet waar ik moest kijken, alles was gewoon mega-awesome.

Er stonden oude computers in het computermuseum, van die superoude dingen. Ze waren zo traag, het was lachen! In de lounge kreeg ik iets dat Club Mate heet, en het smaakte… raar, maar op een goede manier.

Het flexlab was één grote chaos (maar op een leuke manier). Er werd gesoldeerd, en er stond zo’n megagrote machine, ik weet niet eens wat het was, maar het was groots!

En ze vertelden me dat ze bezig waren met een coole werkplaats voor hout en metaal. Serieus, dat klinkt als iets uit een actiefilm.

Oh, en die pannenkoeken! Die waren echt lekker, gewoon jummie!

De lounge is begonnen aan haar grootse make-over. Na weken van schuiven met spullen, maken van een bar, bouwen van Ivars op de juiste plaatsen, en inrichten van de koelkast, van kasten met museum stukken en schilderen begint het ergens op te lijken. Zie onderaan deze blog voor kiekjes!

Ada Lovelace heeft als hacker-avant-la-lettre natuurlijk een ereplaats verdient. Daarom staat ze nu groot op de centrale muur van de lounge. Daarnaast hebben we nu reden om onze lounge de Lovelace Lounge te noemen, wat best lekker klinkt.

En hier is ze dan, haar ogen volgen je overal in de lounge:

Hoe is Ada gemaakt?

Met een stukje touw en wat duckedtape + een potlood heb ik een circkel op de muur getekend. Daarna heb ik met behulp van een beamer een bekend portret van Ada Lovelace geprojecteerd op de muur in de cirkel, en in grove potloodlijnen (met een timmermanspotlood) een schets overgenomen op de muur.

Omdat we een kleine verspringing in bakstenen hebben tussen de muur links van de muurschildering en de muur van de wandschildering, heb ik de groene achtergrondkleur op de scheidslijn laten beginnen. Leuk trucje dat de aandacht afleidt. Aan de andere kant heb ik dezelfde afstand aangehouden.

Ik heb van groot naar klein gewerkt: Eerst het grote groene vlak, toen de cirkel, toen de basiskleuren, en daarna de details.

Een deel is muurverf die over was gebleven uit mijn eigen huis, een deel Amsterdam acrylverf, en een deel bladgoudflakes van de Action op witte houtlijm.

Hier zie je een deel van het proces:

En hier zie je de rest van de huidige status van de Lovelace Lounge.

Dit betekent dat het nu ongeveer tijd is om banken te gaan bestellen. Dus hopelijk kunnen we snel met een grote groep gaan loungen onder het toeziend oog van Ada!

De eerste container heeft zojuist onze binnenplaats verlaten.

🥳

(nu de zeecontainers nog)

Als “verveelde” miljardair lijk je tegenwoordig niet echt mee te tellen zonder je eigen Social Media Platform. Heel Twitter is ook zo’n beetje in rep en roer de afgelopen weken vanwege de overname door Elom Nusk. Iedere dag wordt het weer een stukje duidelijker dat Twitter op het punt van omvallen staat. Dus wat moet je dan als nerd om je FOMO weer onder controle te krijgen met je dagelijkse portie doomscrollen?

Vooral in de infosec community lijkt er een ware stampede (*haha*) naar Mastodon. De intersectie tussen hackers en infoseccers is redelijk groot, dus daar waren we ook al te vinden. Met al die paniek heb je toch het gevoel dat je als hackerspace een keuze moet maken: gaan we ook over? Blijven we dan twitter doen? Volledig focus op mastodon?

En dan, volledig in Hack42-stijl, besluiten we het gewoon anders te doen. “Eigen blog eerst” zeg maar.

En stoppen we dan met tweeten/tooten? Nee joh, we zijn veel te trots op ons volgersaantal… maar voor nu willen we het in ieder geval gewoon weer even SELLUF DOEN. De kwantiteit zal dus omhoog gaan op ons blog, de kwaliteit hopelijk niet al te veel omlaag, en we gaan gewoon lekker social doen op ons eigen platform. Kom maar op met die miljarden!

oh ja, en: #EmbraceTheTyppo

Deelnemers bij hack42 hebben allerlei hobbies. De één stookt zijn eigen drank of maakt toetsenborden op maat, de ander renoveert in zijn of haar vrije tijd een compleet hackerspace pand, koopt pallets vol spullen op of opereert een draaiorgel. En er zijn er ook die graag boeken schrijven of daar een omslag voor ontwerpen.

Vandaar dat er nu in de shop een fysieke kopie van gmc’s eerste novelette (dat is net iets meer woorden dan een kort verhaal, maar ook weer niet zo veel dat het een novella is) staat. Maar niet zomaar een fysieke kopie, want die zijn bij Big Tech ook gewoon te krijgen (net als de e-book variant). Nee, het betreft hier een exemplaar gesigneerd door de auteur (gmc dus) en de ontwerper van de kaft (MacSimski). Allebei door en door Hack42.

Ze verdienen er echter niets aan. De winst, na aftrek van inkoop en verzendkosten, gaat linea recta in de kas van Hack42. Dus zoek je weer eens een excuus om een paar euro aan Hack42 te doneren, lees je graag (Engels-talige) sci-fi en wil je een uniek, genummerd, exemplaar met een persoonlijke boodschap er in van dit debuut, schroom dan niet en bestel!

En als je toch in de shop bent, check gelijk al de andere goodies. Want zeg nou zelf, je kan nooit genoeg Hack42 merchandise in huis hebben, toch?

Begin vorige maand vroegen we om geld, zodat alle wensbare plannen rondom de verbouwing van onze hackerspace kunnen betalen. Hier is fantastisch op gereageerd, maar… wij gaan voor groter en beter!

Daarom herhalen we (nu iedereen hun vakantiegeld gestort heeft gekregen ;-)) nogmaals de vraag: wie kan er wat geld missen en helpt ons met de bouw van onze hackerspace? We hebben nog minimaal 10.000 euro nodig om alle wensbare plannen te kunnen uitvoeren (omdat we voorlopig niet volledig open mogen). We doen alles zelf, dus het sponsorgeld gaat helemaal naar de materialen voor het pand!

Wil je zien wat we wanneer met de ontvangen donaties gaan doen? Je kunt een overzicht van de geplande kosten vinden op onze wiki. Denk hierbij voorbeeld aan; het bouwen van een sanitairblok, het afwerken van het vernieuwde dak, het vervangen van hang- en sluitwerk, het aanleggen van infra, maar ook aan het monteren van zonnepanelen en het vervangen van ramen en kozijnen en een rottende dakbalk.

Je kunt je geld aan ons doneren op de volgende manieren:
– onze webshop
– paypal
– of door geld over te maken naar onze rekening NL17ABNA0572310633 / BIC: ABNANL2A tnv Stichting Hack42 te Arnhem

Voor bedrijven kunnen we een factuur maken. Stuur hiervoor een email naar penningmeester@hack42.nl om verdere details te bespreken.

Hack42 heeft weer wat te kijken en lezen voor je.
We beginnen met onze zesde nieuwsbrief: SPAMSPAMSPAM

Waarin we je bijpraten over wat er in de eerste maanden van dit jaar in de space gebeurd is.
Daarnaast is in de nieuwsbrief ook de eerste Hack42 Klusupdate op youtube te vinden. (Die jullie natuurlijk via ons blog allang hebben gekeken…)

Ondertussen is onze tweede Klusupdate ook alweer uit, dus je kan gelijk doorgaan met filmpjes kijken: