IRC channel logs


back to list of logs

<gnucode>sneek: later tell damo22 Did you ever get the Hurd to run on a T410 ?
<sneek>Got it.
<damo22>sneek: later tell gnucode I don't have a T410, i am working on HP T620 which is an AMD board, see my latest mail to the list
<sneek>damo22, you have 1 message!
<sneek>damo22, gnucode says: Did you ever get the Hurd to run on a T410 ?
<sneek>Got it.
<damo22>i added ACPI >= v2.0 support to gnumach :D
<damo22>if you want some background on what happened with gitea
<damo22>damn, t620 crashes again, but at least i get a log now, except its only visible for a split second
<damo22>it seems to reach atbus
<damo22>it crashes at timer calibration.... CRASH
<damo22>it has about 6-7 clock interrupts
<damo22>hmm it has 2 ioapics
<damo22>the second one is not defined in the vectors so maybe its triggering an interrupt with no vector and crashing?
<anatoly>solid_black: I wonder why does the indented list of packages in contain duplicates from the rest of the list?
<solid_black>the indented list is temporary-ish
<solid_black>the rest is close to what the upstream had
<solid_black>basically the indented list is things that I wanted to get building (and mostly succeeded in it), in the order that we need for e.g. bootstrapping the 'hurd' package
<solid_black>so yes, it's duplicated with the regualr list
<solid_black>we should clean that up
<solid_black>(but that should not cause any issues, abuild skips already-built packages)
<anatoly>I'd keept he original list as comment and build the current one in a clean manner :-)
<solid_black>sure, please feel free to submit PRs / patches / whatever
<anatoly>Yep, I'd guess that it skips, otherwise you wouldm't leave it like this :-)
<solid_black>I'm bootstraping the whole thing again on a different host right now, and will try booting it
<solid_black>still need grub from elsewhere, since ours doesn't yet build
<anatoly>uff, nice
<anatoly>So it will die on the grub from the list
<anatoly>So it will die on the grub from the list?
<solid_black>ok it's broken already 🤦️
<anatoly>I prepped simple Containerfile to run the build process
<anatoly>I guess cross-building will stay for some time?
<solid_black>I think we're probably going to want to use Gitea/Forgejo Actions, thir little GitHub actions Clone?
<solid_black>(err, Actions clone, capitalized the wrong letter)
<solid_black>also we're going to want to detect changed APKBUILD's and only rebuild those, this is what upstream Alpine does
<solid_black>yeah, we'll keep bootstrapping for now probably, but should switch to native builds once the system boots & abuild works inside
<anatoly>Yep, I will look at their gitlab setup to see how they deal with it
<anatoly>I wa thinking to prepapare a container with cross-compiler pre-built, basically up to the step of building that list of packages
<anatoly>I was thinking to prepapare a container with cross-compiler pre-built, basically up to the step of building that list of packages
<solid_black>next thing, I think gnucode is going to run Gitea/Forgejo on his Guix GNU/Linux machine? So for native builds, we'll have to make it spawn qemu
<solid_black>speaking of providing a container with a cross toolchain pre-built: I think this would be a great thing to do even unrelated to this distro project
<solid_black>just so that people who may not even know much about Hurd are able to easily test building their software for the Hurd in their CI
<solid_black>I mean, just an easily usable Docker / OCI image with Debian or something, with a Hurd cross-toolchain installed, so they can just run their builds on CI without having to know anything about the Hurd or how to set it up
<solid_black>ok no, my build is not broken, it's just that I didn't install my signing key into the system-wide trusted keys dir
<solid_black>so apk ignored just-built packages
<solid_black>anatoly: so did you bootstrap it?
<anatoly>it is still building last few package
<solid_black>but that basically means it worked, yay
<anatoly>I should've ran it on a faster machine
<solid_black>fwiw, x86_64-hurd bootstrap currently fails at glibc, because we're using the 2.38 release and there have been incompatible changes to gnumach that require matching glibc updates
<solid_black>I could backport the patches, but let's just wait for the 2.39 release which should happen in a few days
<solid_black>and I'll bump the symbol version to GLIBC_2.39 too, so please don't publish any images until then
<solid_black>after that, we could totally apply my aarch64 patches and builf an aarch64-gnu userland :)
<anatoly>sure, I had no plans, I will first cleanup Containerfile, probably will do fork of your fork and will commit on top of hurd branch
<solid_black>any ideas for the name btw?
<anatoly>I have Quartz64 board
<anatoly>Nope, nothing came to my mind do far
<anatoly>*so far
<solid_black>how does "Mont Blanc Hurd" sound for example?
<solid_black>do you have experience with bare metal arm/aarch64 hacking?
<anatoly>no :-D
<solid_black>welp, me neither
<solid_black>guess we'll just wait for Luca then
<anatoly>I mean as a test run cross-build on arm, probably won't be faster than in qemu on fast x86 :-D
<solid_black>yes, but it's important that it works on real arm boards and not just in qemu, 'cause as I understand it there's lots and lots of variation, and qemu only implements a fraction of it
<solid_black>also people who own arm boards are more likely to have experience with the low level details of it
<solid_black>I don't think "hurd" should be melded into another word? I'd rather have Something Hurd than Somethinghurd
<anatoly>It is mt. Matterhorn so I played with the word :-)
<anatoly>some people buy arm-boards to blink with a led few times and then collect dust with it :-D
<anatoly>Aoraki Hurd? aka Mount Cook Hurd :-)
<solid_black>naming things is truly the hardest problem in computer science :)
<solid_black>thanks for the suggestions
<solid_black>of the things suggested so far, I like Everest Hurd most; if only it wasn't for Everest Linux :(
<anatoly>Etna Hurd, trully belissimo Hurd distro
<anatoly>Ok, it stopped building
<anatoly>as expected
<solid_black>Etna Hurd sounds quite ok actually!
<solid_black>so, you should have lots of packages in ~/packages/main/x86-hurd/
<solid_black>and the cross toolchain packages in ~/packages/main/x86_64/
<anatoly>Btw, regarding the patch for /usr/share/abuild/, would pre-building patched version of abuild package for linux be the solution? So as a separate process build it for alpine linux witht he patch applied and then put it into a repo which is added when bootstrapping hurd?
<solid_black>that makes sense, yes; I already apply the same patch when building abuild for the target system
<anatoly>324 packages in main/x86-hurd
<damo22>Solid Hurd
<anatoly>solid_black: which packages do you choose when you do apk add, I guess it should be all because they are a part of base system?
<solid_black>it depends on what you want? but the base system needs something like hurd, openrc, busybox to even boot
<solid_black>(this is theoretical, I haven't tried booting it just yet)
<solid_black>you also probably going to want alpine-base
<solid_black>oh and gnumach of course, don't forget that one :)
<solid_black>alpine-base depends on busybox and openrc, so you could narrow that down to gnumach, hurd, alpine-base
<anatoly>I will try it at some point but I will concentrate on the building tools in preparation for CI
<anatoly>solid_black: can we take alpine qemu image, keep grub and replace the rest with packages for hurd?
<solid_black>we don't even need the alpine image for that
<solid_black>we can run grub-install from anywhere (Debian for example)
<solid_black>eventually we'll want to build our own grub of course
<anatoly>yeah, true
<anatoly>solid_black: something like this ?
<solid_black>fwiw there are other scripts in scripts/ that build images
<anatoly>hm, good point :-)
<damo22>even with these three commits, my t620 board still crashes when you enable interrupts to calibrate the timer:
<damo22>* e88639b0 (HEAD -> fix-ioapic, zam/fix-ioapic) apic: Support 48 interrupts and up to two IOAPICs
<damo22>* d4388546 ACPI: Support XSDT (ACPI >= v2.0)
<damo22>* fd0958d5 ioapic: Remove IMCR toggle
<damo22>youpi: any ideas?
<damo22>i know everyone here has their own hurd projects, but it would be nice if someone helps with gnumach for more hardware support
<damo22>or userspace drivers
<damo22>acpi v2 is a blocker for most modern hw, so i pushed hard on that one
<damo22>but theres still problems to fix
<solid_black>I'd love to, but I have zero idea about anything hardware related, sorry
<damo22>i had very little knowledge of that either a few years ago
<solid_black>oh, perhaps you could share which resources you found useful to learn this stuff?
<damo22>i use the source like a reference
<damo22>since it implements the firmware needed to bring up the board, you can see what stuff is exposed from a board port
<damo22>netbsd kernel source is useful to study for ideas too
<damo22>if you want to see some particular quirk of hardware, use the linux source
<janneke>damo22: yay for acpi v2
<janneke>also, rumpdisk enabled me to install the hurd on a T60
<damo22>i have hurd booting in PIC mode on an HP T620
<damo22>but to make the NIC work, i need APIC mode
<damo22>and ACPI v2
<damo22>solid_black: you could find a board that you want to use as a server, that has an existing coreboot port, buy a usb->serial dongle and connect it up to your dev machine via com0 and try to make it boot hurd
<solid_black>I know I'm the one who's always saying that one learns things by trying to do something and seeing what breaks, but this never seemed to work for me for the hardware part
<damo22>software engineering is useless without hardware
<solid_black>but it looks like I'm just missing some fundamental understanding of how things fit together
<damo22>you need to know hardware 101, basically how to wire up a serial port
<solid_black>something I've observed others have natural understanding of
<solid_black>yes, I don't even know what a serial port is, other than that it's a port that you could connect to and maybe get output from (and a console on)
<damo22>in its simplest form, it has 2 wires, tx and rx
<damo22>transmit and receive
<damo22>probably ground as well
<solid_black>ok, so how does one send something over the wire?
<solid_black>does it send bits? bytes? does one vary electricity? (current?)
<damo22>you just need to connect tx -> rx on each side
<solid_black>what does that mean?
<solid_black>connect how?
<damo22>each wire has a node that is labelled, and the signal passing through it is called something
<damo22>so on one side of a serial connection, there are TX and RX endpoints
<damo22>one of them transmits data, one of them receives data
<damo22>to make a serial connection between two pcs, you just cross over the TX -> RX on each side
<damo22>which is usually done with a "null modem" cable that plugs into a db-9 jack on each side
<solid_black>I don't think I understand what any of that means, sorry :(
<youpi>solid_black: on side puts e.g. 5V on the wire
<youpi>the other side can measure that
<youpi>that's how you can transmit a 1
<youpi>and you can use e.g. 0V or -5V to transmit a 0
<solid_black>ok, that's clearer, thanks
<youpi>then both sides "just" need to agree on the speed at which 0s and 1s god
<solid_black>is 5V an actual value that is commonly used, or just a placeholder?
<youpi>it's an actual value for some of the existing standards
<youpi>also, you need a start sequence
<youpi>so that the receive knows when it starts
<solid_black>is there some acknowlegdement / "wait, I didn't get it, send it again" mechanism, like in TCP?
<youpi>the serial port doesn't implement that
<youpi>it's up to the application to handle that
<youpi>through checksums etc.
<solid_black>also, and this might be a dump question, but how do you put some voltage onto the wire? I imagined voltage is something that you can have *between* two pins in a single circuit
<damo22>there is a ground wire on each side
<youpi>there is also a ground pin, yes
<solid_black>so is there then a (commonly used) higher level protocol on top that lets you reliably transmit stuff?
<youpi>usually yes
<youpi>for a dumb terminal that just shows the text, you don't care
<solid_black>so when I say console=com0, is that higher level protocol getting used?
<youpi>you might get glitches, but for small cables that's rare enough
<youpi>but that's fine enough
<youpi>that's not reliable for transmitting data of course, but then you'd use specialized tools
<solid_black>so this seems to be a mechanism for transferring individual bits so far
<youpi>like sz
<youpi>the serial port will send 7 or 8 bits at a time, with the start squence before it, and possible a parity bit after
<solid_black>what does "at a time" mean here?
<solid_black>does it like, send bits in bursts?
<youpi>cadences at the configured bps (or baud)
<solid_black>right, I've heard the term "baud rate" thrown around serial ports
<damo22>its the number of bits per second being sent
<youpi>that's it
<solid_black>bits per second?
<solid_black>I see, thanks
<youpi>which is not the obtained bit per second of the transfer, since the start sequence and the parity bits also take some time
<solid_black>so what would a typical value for baud rate be
<youpi>38400 sometimes
<damo22>your getty shell uses 38400
<youpi>57600, also
<youpi>(the famous 56k modems)
<youpi>see the B* macros: B9600, B115200 etc.
<solid_black>ok, so 38400 bits per second, including special ones like partity bits, so that would be in the order of 4k bytes per second?
<youpi>(your questions are really not dumb, they're right on the spot)
<solid_black>of payload
<youpi>that's the kind of speed you had with 56k modems :)
<damo22>it would be very helpful if this becomes part of your knowledge so we can collaborate on gnumach
<youpi>my first Internet connection was at 2400 baud
<solid_black>how is this related to modems? do modems use the same serial ports?
<youpi>they're connected through a serial cable yes
<youpi>on the serial port
<youpi>the modem itself also sends the bits on the telephone line
<youpi>it's not just +5V/-5V, there is modulation
<solid_black>what else are serial ports/cables used for? I've only heard about them being used for getting a console basically so far
<youpi>but apart from the electric details, the principle is the same
<youpi>eeprom flashing devices
<youpi>Braille devices
<damo22>many industrial peripherals use serial ports
<solid_black>that modem sits in between a computer and the telephone line I understand, yes
<damo22>cash acceptors
<solid_black>I'm not *that* young, I remember a time where I could not use my granddad's PC when my grandma was talking on the phone :D
<solid_black>ok, eeprom is also the term I've heard somewhere, perhaps related to flashing indeed
<damo22>probably industrial facilities use serial ports to interconnect heavy machinery with a central pc
<solid_black>how does using a serial port connected to a modem to access Internet compare to using an Ethernet connection?
<damo22>in Australia, dial up modem is better
<solid_black>what is the interface called (instead of eth0)? is there a local network, do you have peers? is there a protocol used between the oc and the modem, for ensuring integrity?
<solid_black>I don't mean better or worse of course ;)
<youpi>solid_black: serial ports are *way* simpler than ethernet
<youpi>that's why people use that
<youpi>it's cheaper :)
<youpi>between the pc and the modem there is just the parity bit that checks some integrity, but that's very weak
<solid_black>hm, so I imagine you need _an ethernet card_ (& drivers for it / netdde) to connect via ethernet?
<youpi>again, we use higher-level protocols for checksums
<solid_black>but not for a serial port?
<youpi>depends what you do
<biblio>solid_black: use-case
<youpi>modems and serial ports have a weak parity bit
<youpi>that's fine enough for displaying stuff on a terminal
<youpi>for sending data, you'll add checksums
<youpi>solid_black: to connect via ethernet you need an ethernet card indeed
<youpi>to connect to the internet via a modem, ethernet is not involed, you use ppp
<damo22>bidirectional serial connection needs just a pair of pre-negotiated speeds and 3 wires...
<youpi>which puts the ip packet in a ppp frame (basically just encodes the bytes, managing the limitation to 7 bit if any)
<solid_black>aha, so ppp is a "physical" level protocol, just like ethernet? but simpler?
<youpi>no it's not physical
<youpi>it's completely software
<youpi>you configure ppp to use the serial port to send the data of the ppp frame
<solid_black>physical as in the OCI layer
<youpi>and that goes over the modem
<youpi>it's the link-layer
<youpi>just above the physical
<youpi>and just below the network layer
<solid_black>I see
<solid_black>and you're only connected to the modem on the other side, there are no peers?
<solid_black>what is your local network then, and how do you get an IP address assigned?
<damo22>as an example, my T620 is connected with a crossover serial cable to my laptops serial port, and i set both speeds to 115200, and when i type into a minicom console configured for the right serial port, the text appears in the other side if its listening
<youpi>solid_black: on the other side you have the same
<youpi>another modem, another serial cable, and another pc that does the converse
<youpi>unpacking the ppp frame, etc.
<youpi>for ip assignation: it's part of the ppp protocol, there is a negociation step when you connect
<youpi>(which is still used nowadays with dsl and even ftth)
<damo22>solid_black: if you want to port an ARM board
<damo22>using your new toolchain, you can use a serial port
<damo22>to monitor the kernel log
<solid_black>alright, another dumb question: how do I even know if I have a serial port?
<solid_black>I imagine my phone doesn't have one for example?
<solid_black>what does it look like?
<solid_black>can it look like anything, as long as there are two wires?
<damo22>your phone has lots of them, bluetooth is basically a serial port over the air
<solid_black>I've also heard something about USB ports and headphone jacks being used as serial ports?
<solid_black>bluetooth is a serial port???
<youpi>solid_black: you'll want 3 wires, for the ground and both directions
<youpi>yes it is
<solid_black>ah, right
<youpi>usb is, too
<youpi>it's a "bit" more complex, but basically it's a serial port, yes
<damo22>Universal Serial Bus
<youpi>as for proper serial port (as in recognized by e.g. a modem), it's the DB-9 or DB-25 plugs
<solid_black>ok, there must be a difference between "a serial port" (as in, some sort of a port that is serial, not parallel), and the specific sort of a serial port that we were talking about? is there a specific name for the latter?
<youpi>you'll easily find usb-to-db-9 converters
<solid_black>ACTION looks it up
<damo22>also, if you dig into coreboot, you will find that most boards that have native serial ports are provided by a "super i/o" chip, and these have pins you can use directly
<youpi>sometimes the pin are not plugged to an actual db-9 plug
<youpi>but you can plug one :)
<solid_black>I don't think I understand what that means either -- "super i/o chip"? "pins you can use directly"?
<youpi>super-i/O is just that that chip integrates various i/o interfaces
<youpi>serial port included
<youpi>so you can just plug to the pins of the chip that provides the serial port
<solid_black>also: do these two (or three?) wires plug directly onto a pin on the CPU?
<youpi>not the cpu
<youpi>it's a separate chip on the board
<solid_black>how does the CPU control voltage?
<youpi>it doesn't :)
<youpi>the i/o chip does
<youpi>through transistors etc.
<damo22>now you are asking more hardware questions!
<solid_black>I imagine I need to do some x86 in/out from software; what does that actually do?
<solid_black>other than "perform I/O", which says nothing
<solid_black>does that modify some voltage between some pins?
<youpi>yes, you'd out(0x378) to send a byte on the serial port
<youpi>which makes the cpu write the byte on the data bus of the board
<youpi>and the i/o chip catches it, and sends it on the serial port
<solid_black>ok, so there is a data bus!
<youpi>between the cpu and the rest of the board yes
<youpi>(memory, pci cards, etc.)
<youpi>it's parallel bus
<solid_black>is 0x378 some sort of an address on that bus?
<damo22>0x3f8 is usually com0
<youpi>it's kinda special with x86 but that's the idea
<youpi>(on most hardware it's just an address in "memory" which happens not to be actual memory, but the i/o chip)
<youpi>ah, I wrote 378 above, I meant 3f8 yes
<youpi>378 would be the parallel port :)
<solid_black>my (probably naive, please correct me) understanding was that "x86" (or IA-32 or whatever) is the ISA of the CPU, and then there's a technically orthogonal thing called "IBM PC compatible" (which gnumach calls "at"?) which specifies the "platform", including at which addresses devices are memory-mapped, and probably things like this 0x378
<youpi>that's it, yes
<youpi>(it's not naive at all, most people don't understand it :) )
<youpi>the in/out instructions in the intel manual don't specify anything about the meaning of the address
<solid_black>is this data bus itself standardized? (between different IBM PC compatibles? different CPU architectures? different "platforms"?)
<youpi>it is somewhat
<youpi>e.g. you have the PCI standard, but the CPU usually doesn't directly speak PCI
<youpi>though it could
<youpi>so most often you have a chip on the board that connects the cpu to the rest of the world (pci, pci-x etc.)
<youpi>but from a programmatic point of view on the cpu, you don't care about that interconnexion, you just use in/out
<youpi>and the chip handles routing to the proper device
<youpi>ooooh, that good old document, still there around :D
<solid_black>how does memory mapped I/O work? I think I read somewhere that there is a single memory bus, which all the memory-mapped devices (including the RAM? can there be several instances of the RAM btw?) are connected to, and each devices only responds to requests about addresses that it "knows" it's mapped to
<youpi>it's the board that manages the mapping
<solid_black>does the CPU itself (as opposed to software running on it) know whether some address is memory-mapped or not?
<youpi>no it doesn't
<solid_black>what does "the board" mean here?
<youpi>whatever is around the cpu :)
<youpi>quite often a single chip
<youpi>sometimes you had two northbridge and southbridge chips
<youpi>to separate PCI, ISA, AGP, whatever
<youpi>but from the point of view of the cpu it's just "the mainboard"
<solid_black>ok then, how come prefetching / speculative execution does not mess with mmio?
<youpi>it does
<solid_black>it does??
<youpi>if you don't configure the cpu properly
<youpi>you have to tell e.g. in the page table "no cache"
<solid_black>I see
<solid_black>so the cpu really has no idea on its own, the software must do it
<youpi>the software knows what is proper ram from the bios
<youpi>the e820 table
<youpi>the bios being very knowledged how to ask that from the board
<solid_black>is bios like efi boot services or runtime services? iow, does it stay resident after boot?
<youpi>it can, yes
<youpi>you have some int service in real mode, and bios32 in protected mode
<damo22>bios in terms of coreboot has two main phases: bringup of the mainboard, and "payload" or something to hand off execution to
<youpi>(int 16h for the real mode)
<solid_black>"where" is it? is it just some code that the cpu jumps to (via an interrupt handler?), or some special magic?
<youpi>it's at 0xf0000-0xfffff
<solid_black>does the kernel have to be careful to not touch the physical pages used by that bios
<youpi>the int 0x16 is plugged to it, yes
<youpi>it has to yes
<youpi>that's said so in e820
<youpi>the vga, network, etc. cards can also have some rom between 0xc0000 and 0xeffff
<solid_black>can userland just raise any interrupt? it certainly can raise int 0x80; what prevents it from raising 0x16?
<youpi>biosmem: 0000000000000f0000:000000000000100000, reserved
<youpi>that's it
<youpi>solid_black: it cannot
<solid_black>ah, so that's what biosmem means
<damo22>0xb8000 has the text frame buffer
<youpi>biosmem is just the gnumach name for parsing e820
<youpi>solid_black: I don't remember exactly, but most probably it's the int table that says from which rings an interrupt can be called
<damo22>heres a real question : Why would a board crash if you enable interrupts but the timer interrupt fires 6 or 7 times first?
<youpi>depends what you call "crash"
<damo22>it reboots
<youpi>do you have the reason for the reboot?
<youpi>"reboot" is normally a cpu thing
<youpi>that can be due to stack overflow
<youpi>or triple-fault
<damo22>hmm, i am pretty sure i added 48 interrupt vectors for both IOAPICs
<damo22>and programmed them both
<damo22>it faults just as i am calibrating the lapic timer
<damo22>maybe the timer expires and calls an invalid interrupt?
<damo22>does this work on AMD x86? asm volatile ("pause" : : : "memory")
<youpi>pause is a quite old additions, so I guess it should be ok
<damo22>i used grub> lsacpi
<damo22>one of the lines that is interesting is LAPIC_NMI ACPI_ID=ff flags=0005 lint=01
<damo22>the rest are supported by gnumach
<damo22>but i dont know what that one is for
<damo22>its an acpi irq override
<damo22>non-maskable interrupt, not sure if its required to boot the machine
<saravia`>Hi colleges <-- I was lerning over 6 years for come to here ... I think, I'm ready for use hurd
<saravia`>u_u... one question, one version of gnu distro which works with hurd fisical?
<etno>saravia`: hi! I am rather new here, but I think that the question is not so much about the disto, but rather about the hardware. It would seem that most people laying around here have Hurd working with Thinkpad machines. Although qemu is the big contender.
<etno>disto -> distro
<gnucode>etno: You could try a T60
<sneek>Welcome back gnucode, you have 1 message!
<sneek>gnucode, damo22 says: I don't have a T410, i am working on HP T620 which is an AMD board, see my latest mail to the list
<gnucode>That's a really old Thinkpad that some Hurd people use in real hardware
<gnucode>I am trying to install the Hurd in a T410. The installer boots and is able to access the internet from the ethernet port.
<etno>gnucode: at some point, I may buy such a machine if I get tired of trying :-) So far, I still have hope with my spare laptop. And there is a chance that I fix stuff while fighting.
<etno>I believe I solved an FPU initialization issue already 🎉
<gnucode>etno: I have the Hurd running in a T43. That machine is really pretty stable. :)
<damo22>saravia``: if you want hurd on real hardware (not qemu) there are limited choices at the moment
<anatoly>I remember running it on an asus eeepc 90x series netbook loong time ago :-)
<gnucode>damo22: We should probably have a list of machines that you can buy that people run the Hurd on. And we should add it to the manual/ wiki
<damo22>i dont think that is so useful because the list should be very long
<damo22>and we want to encourage people to try new ones
<gnucode>sneek later tell solid_black I have a very very simple website set up with emacs' org-mode
<sneek>Will do.
<gnucode>damo22: I think that list would still be useful for people to know.
<gnucode>T60, T43,