* [TUHS] Unix taste (Re: terminal - just for fun) @ 2014-08-04 20:21 Norman Wilson 2014-08-04 22:24 ` A. P. Garcia 0 siblings, 1 reply; 11+ messages in thread From: Norman Wilson @ 2014-08-04 20:21 UTC (permalink / raw) Larry McVoy: Looking at git like that is sort of like looking at the size of a dynamically linked app. Ya gotta add in libc and all the extensions people use to make it not suck. ===== In which case one should also add the size of the kernel, or at least the code paths exercised by a given program. Not to mention the layers of window systems, networking, desktops, message buses, name-space managers, programs to emulate 40-year-old terminal hardware, flashy icons, and so on. I say all this to underscore Larry's point, not to dispute it. Everything has gotten more complicated. Some of the complexity involves reasonable tradeoffs (the move toward replacing binary interfaces with readable text where space and time are nowhere near critical, like the /proc and /sys trees in modern Linux). Some reflects the more-complex world we live in (networking). But a lot of it seems, to my mind that felt really at home when it first settled into UNIX in 1981, just plain tasteless. There are certainly legitimate differences in aesthetic taste involved, though. I think taste becomes technically important when it can be mapped onto real differences in how easily a program can be understood, whether its innards or its external interface; how easily the program can adapt to different tasks or environments; and so on. Norman Wilson Toronto ON ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun) 2014-08-04 20:21 [TUHS] Unix taste (Re: terminal - just for fun) Norman Wilson @ 2014-08-04 22:24 ` A. P. Garcia 2014-08-04 22:23 ` [TUHS] /proc - linux vs solaris Larry McVoy 2014-08-05 2:41 ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela 0 siblings, 2 replies; 11+ messages in thread From: A. P. Garcia @ 2014-08-04 22:24 UTC (permalink / raw) On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote: <snip> > Everything has gotten more complicated. Some of the complexity > involves reasonable tradeoffs (the move toward replacing binary > interfaces with readable text where space and time are nowhere > near critical, like the /proc and /sys trees in modern Linux). <snip> To digress from the main topic, I realize that's just one example, but here's a counterpoint to it: We in Solaris designed /proc as a tool for developers to build innovative solutions, not an end-user interface. The Linux community believes that 'cat /proc/self/maps' is the best user interface, while we believe that pmap(1) is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M) and a host of other tools all make use of this same information. It would be a waste of time to take binary information in the kernel, convert it to text, and then have the userland components all write their own (error prone) parsing routines to convert this information back into a custom binary form. Plus, we can change the options and output format of pmap without breaking other applications that depend on the contents of /proc. [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/54f140ed/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-04 22:24 ` A. P. Garcia @ 2014-08-04 22:23 ` Larry McVoy 2014-08-04 23:11 ` Larry McVoy 2014-08-05 12:06 ` Tim Bradshaw 2014-08-05 2:41 ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela 1 sibling, 2 replies; 11+ messages in thread From: Larry McVoy @ 2014-08-04 22:23 UTC (permalink / raw) On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote: > We in Solaris designed /proc as a tool for developers to build innovative > solutions, not an end-user interface. The Linux community believes that > 'cat /proc/self/maps' is the best user interface, while we believe that > pmap(1) is right answer. The reason for this is that mdb(1), truss(1), > dtrace(1M) and a host of other tools all make use of this same information. > It would be a waste of time to take binary information in the kernel, > convert it to text, and then have the userland components all write their > own (error prone) parsing routines to convert this information back into a > custom binary form. Plus, we can change the options and output format of > pmap without breaking other applications that depend on the contents of > /proc. I come from SunOS background and have had more than a few /proc discussions with Roger Faulkner (who I believed did the System V /proc at Bell Labs?). I get the arguments above but I don't buy 'em. linux really got /proc right in terms of usefulness. Digging binary blobs out of the kernel and translating them sucks. I've done, I've written kmem drivers for ps, I understand how it works. I far prefer the pure ascii model that Linux has. I also get that Linux turned /proc into /whatever/I/think/I/need/today and that makes purists grit their teeth. None the less, if you give me a choice I'll take the linux way. Want to see what files you have open? ls -l /proc/$$/fd Etc. Really easy to poke around and figure stuff out as needed and no rats nest of header files to decode the structures. --lm ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-04 22:23 ` [TUHS] /proc - linux vs solaris Larry McVoy @ 2014-08-04 23:11 ` Larry McVoy 2014-08-05 1:26 ` A. P. Garcia 2014-08-05 12:06 ` Tim Bradshaw 1 sibling, 1 reply; 11+ messages in thread From: Larry McVoy @ 2014-08-04 23:11 UTC (permalink / raw) Seem like even Roger liked it: https://lwn.net/lwn/1998/0226/sunproc.html On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote: > On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote: > > We in Solaris designed /proc as a tool for developers to build innovative > > solutions, not an end-user interface. The Linux community believes that > > 'cat /proc/self/maps' is the best user interface, while we believe that > > pmap(1) is right answer. The reason for this is that mdb(1), truss(1), > > dtrace(1M) and a host of other tools all make use of this same information. > > It would be a waste of time to take binary information in the kernel, > > convert it to text, and then have the userland components all write their > > own (error prone) parsing routines to convert this information back into a > > custom binary form. Plus, we can change the options and output format of > > pmap without breaking other applications that depend on the contents of > > /proc. > > I come from SunOS background and have had more than a few /proc discussions > with Roger Faulkner (who I believed did the System V /proc at Bell Labs?). > > I get the arguments above but I don't buy 'em. linux really got /proc > right in terms of usefulness. Digging binary blobs out of the kernel > and translating them sucks. I've done, I've written kmem drivers for > ps, I understand how it works. I far prefer the pure ascii model that > Linux has. > > I also get that Linux turned /proc into /whatever/I/think/I/need/today > and that makes purists grit their teeth. None the less, if you give > me a choice I'll take the linux way. Want to see what files you have > open? > > ls -l /proc/$$/fd > > Etc. Really easy to poke around and figure stuff out as needed and no > rats nest of header files to decode the structures. > > --lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-04 23:11 ` Larry McVoy @ 2014-08-05 1:26 ` A. P. Garcia 2014-08-05 11:55 ` A. P. Garcia 0 siblings, 1 reply; 11+ messages in thread From: A. P. Garcia @ 2014-08-05 1:26 UTC (permalink / raw) On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm at mcvoy.com> wrote: > > Seem like even Roger liked it: > > https://lwn.net/lwn/1998/0226/sunproc.html :-) There are a few different issues here. Linux exports a lot of interesting info that Solaris doesn't. It's hard not to like that. Where they put it, who cares. The unix filesystem hierarchy wasn't exactly planned out by neat freaks. > On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote: > > On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote: > > > We in Solaris designed /proc as a tool for developers to build innovative > > > solutions, not an end-user interface. The Linux community believes that > > > 'cat /proc/self/maps' is the best user interface, while we believe that > > > pmap(1) is right answer. The reason for this is that mdb(1), truss(1), > > > dtrace(1M) and a host of other tools all make use of this same information. > > > It would be a waste of time to take binary information in the kernel, > > > convert it to text, and then have the userland components all write their > > > own (error prone) parsing routines to convert this information back into a > > > custom binary form. Plus, we can change the options and output format of > > > pmap without breaking other applications that depend on the contents of > > > /proc. > > > > I come from SunOS background and have had more than a few /proc discussions > > with Roger Faulkner (who I believed did the System V /proc at Bell Labs?). > > > > I get the arguments above but I don't buy 'em. linux really got /proc > > right in terms of usefulness. > Digging binary blobs out of the kernel > > and translating them sucks. I've done, I've written kmem drivers for > > ps, I understand how it works. I far prefer the pure ascii model that > > Linux has. Part of the argument was more or less that the binary model allows a richer set of tools to be built on top of it, and that those tools provide a better interface to the info. Does Solaris have a richer set of tools than Linux in this regard? I think so, but I don't know how much of this is owed to the difference between binary and text interfaces in /proc. Last time I checked, Linix had no pcred(1), for example. top(1) doesn't provide nearly as much info as prstat(1) -- for example, prstat -mL. Why that is, I don't know. Plus, prstat is marginally less resource intensive. Anything as sweet as (k)mdb in linux? Forget it. Maybe that's because Linus was so resistant to having a debugger in the kernel for so long? DTrace? Well, sort of -- a port of dtrace! But I'm really at an unfair disadvantage here. *Why* Solaris has such better tools, you would know better than me. I only know that it does. As for the second part, that writing the tools that use the binary interface is unpleasant, again I have to defer to you. I've never done that. > > I also get that Linux turned /proc into /whatever/I/think/I/need/today > > and that makes purists grit their teeth. None the less, if you give > > me a choice I'll take the linux way. Want to see what files you have > > open? > > > > ls -l /proc/$$/fd I think this would work in solaris, maybe linux too: pfiles $$ > > Etc. Really easy to poke around and figure stuff out as needed and no > > rats nest of header files to decode the structures. Again, that's what the tools are for. If a tool doesn't give me the info I need in Solaris, I guess I'm SOL. In Linux, *maybe* I'd have a chance of finding it in /proc. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/2a6cf51a/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-05 1:26 ` A. P. Garcia @ 2014-08-05 11:55 ` A. P. Garcia 0 siblings, 0 replies; 11+ messages in thread From: A. P. Garcia @ 2014-08-05 11:55 UTC (permalink / raw) After sleeping on this, I realized that with DTrace, the extra goodies exported by linux in /proc may be superfluous. Which would just mean that a nice innovation was perhaps trumped by a more powerful one. However, some of the missing commands in linux-ptools should be trivial to add, and it's somewhat curious that no one has (pcred, pfiles). The one possible exception to this is prstat. On Aug 4, 2014 8:26 PM, "A. P. Garcia" <a.phillip.garcia at gmail.com> wrote: > > On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm at mcvoy.com> wrote: > > > > Seem like even Roger liked it: > > > > https://lwn.net/lwn/1998/0226/sunproc.html > > :-) There are a few different issues here. Linux exports a lot of > interesting info that Solaris doesn't. It's hard not to like that. Where > they put it, who cares. The unix filesystem hierarchy wasn't exactly > planned out by neat freaks. > > > On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote: > > > On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote: > > > > We in Solaris designed /proc as a tool for developers to build > innovative > > > > solutions, not an end-user interface. The Linux community believes > that > > > > 'cat /proc/self/maps' is the best user interface, while we believe > that > > > > pmap(1) is right answer. The reason for this is that mdb(1), > truss(1), > > > > dtrace(1M) and a host of other tools all make use of this same > information. > > > > It would be a waste of time to take binary information in the kernel, > > > > convert it to text, and then have the userland components all write > their > > > > own (error prone) parsing routines to convert this information back > into a > > > > custom binary form. Plus, we can change the options and output > format of > > > > pmap without breaking other applications that depend on the contents > of > > > > /proc. > > > > > > I come from SunOS background and have had more than a few /proc > discussions > > > with Roger Faulkner (who I believed did the System V /proc at Bell > Labs?). > > > > > > I get the arguments above but I don't buy 'em. linux really got /proc > > > right in terms of usefulness. > > > Digging binary blobs out of the kernel > > > and translating them sucks. I've done, I've written kmem drivers for > > > ps, I understand how it works. I far prefer the pure ascii model that > > > Linux has. > > Part of the argument was more or less that the binary model allows a > richer set of tools to be built on top of it, and that those tools provide > a better interface to the info. Does Solaris have a richer set of tools > than Linux in this regard? I think so, but I don't know how much of this is > owed to the difference between binary and text interfaces in /proc. > > Last time I checked, Linix had no pcred(1), for example. top(1) doesn't > provide nearly as much info as prstat(1) -- for example, prstat -mL. Why > that is, I don't know. Plus, prstat is marginally less resource intensive. > Anything as sweet as (k)mdb in linux? Forget it. Maybe that's because Linus > was so resistant to having a debugger in the kernel for so long? DTrace? > Well, sort of -- a port of dtrace! But I'm really at an unfair disadvantage > here. *Why* Solaris has such better tools, you would know better than me. I > only know that it does. As for the second part, that writing the tools that > use the binary interface is unpleasant, again I have to defer to you. I've > never done that. > > > > I also get that Linux turned /proc into /whatever/I/think/I/need/today > > > and that makes purists grit their teeth. None the less, if you give > > > me a choice I'll take the linux way. Want to see what files you have > > > open? > > > > > > ls -l /proc/$$/fd > > I think this would work in solaris, maybe linux too: pfiles $$ > > > > Etc. Really easy to poke around and figure stuff out as needed and no > > > rats nest of header files to decode the structures. > > Again, that's what the tools are for. If a tool doesn't give me the info I > need in Solaris, I guess I'm SOL. In Linux, *maybe* I'd have a chance of > finding it in /proc. :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140805/feb33982/attachment.html> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-04 22:23 ` [TUHS] /proc - linux vs solaris Larry McVoy 2014-08-04 23:11 ` Larry McVoy @ 2014-08-05 12:06 ` Tim Bradshaw 2014-08-05 12:37 ` Steffen Nurpmeso 1 sibling, 1 reply; 11+ messages in thread From: Tim Bradshaw @ 2014-08-05 12:06 UTC (permalink / raw) On 4 Aug 2014, at 23:23, Larry McVoy <lm at mcvoy.com> wrote: > I get the arguments above but I don't buy 'em. linux really got /proc > right in terms of usefulness. Digging binary blobs out of the kernel > and translating them sucks. I've done, I've written kmem drivers for > ps, I understand how it works. I far prefer the pure ascii model that > Linux has. I agree with this, with one caveat: there are things which exist in /proc which should be in a standard format (extensible if need be) but are not. I forget the particular example but I've written patches for, I think, node.js which essentially came down to "add yet another special case for /proc/<whatever>", when there was just no reason that the thing should not have been in a standard format in the first place. Certainly as a user of Solaris and Linux, Linux's /proc is just far more useful (though I like pmap). ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] /proc - linux vs solaris 2014-08-05 12:06 ` Tim Bradshaw @ 2014-08-05 12:37 ` Steffen Nurpmeso 0 siblings, 0 replies; 11+ messages in thread From: Steffen Nurpmeso @ 2014-08-05 12:37 UTC (permalink / raw) |> I get the arguments above but I don't buy 'em. linux really got /proc |> right in terms of usefulness. Digging binary blobs out of the kernel |I agree with this, with one caveat: there are things which \ |exist in /proc which should be in a standard format (extensible \ |if need be) but are not. I forget the particular example \ Whereas unprofessional i missed the most any documentation; if i recall correctly (i think i do) in at least the 2.4 series there was a PROCFSENTRY() (or quite similar) macro which well did what it says and i still don't understand why there was no, and may it be optional, and may the final usage of it be optional in addition, documentational string argument for this. That is i found, and again found some years ago when i first installed Linux on this Notebook and tried to get the fans controlled, that it is completely intransparent; how easy would it be if each entry in proc had a xy.txt that simply expands to the the content of the mentioned string argument? Like it was it took hours to get the fans right. How nice it was once i switched over to (then Free) BSD, which documents not not nil (as in [1]). [1] <http://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-current> --steffen ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun) 2014-08-04 22:24 ` A. P. Garcia 2014-08-04 22:23 ` [TUHS] /proc - linux vs solaris Larry McVoy @ 2014-08-05 2:41 ` Andy Kosela 2014-08-05 3:32 ` Warner Losh 2014-08-05 9:48 ` [TUHS] procfs on FreeBSD (WAS: Re: Unix taste) Dario Niedermann 1 sibling, 2 replies; 11+ messages in thread From: Andy Kosela @ 2014-08-05 2:41 UTC (permalink / raw) On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote: > > On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote: > > <snip> > > >> Everything has gotten more complicated. Some of the complexity >> involves reasonable tradeoffs (the move toward replacing binary >> interfaces with readable text where space and time are nowhere >> near critical, like the /proc and /sys trees in modern Linux). > <snip> > > To digress from the main topic, I realize that's just one example, but > here's a counterpoint to it: > > We in Solaris designed /proc as a tool for developers to build innovative > solutions, not an end-user interface. The Linux community believes that 'cat > /proc/self/maps' is the best user interface, while we believe that pmap(1) > is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M) > and a host of other tools all make use of this same information. It would be > a waste of time to take binary information in the kernel, convert it to > text, and then have the userland components all write their own (error > prone) parsing routines to convert this information back into a custom > binary form. Plus, we can change the options and output format of pmap > without breaking other applications that depend on the contents of /proc. > > [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc] Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1) and ptrace(2). I am still not too sure if it was the Right Thing(r) to do though. The decision was more based on the premise that procfs(4) was neglected in recent years than on anything else[0]. [0] http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-procstat-td4028960.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun) 2014-08-05 2:41 ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela @ 2014-08-05 3:32 ` Warner Losh 2014-08-05 9:48 ` [TUHS] procfs on FreeBSD (WAS: Re: Unix taste) Dario Niedermann 1 sibling, 0 replies; 11+ messages in thread From: Warner Losh @ 2014-08-05 3:32 UTC (permalink / raw) On Aug 4, 2014, at 8:41 PM, Andy Kosela <akosela at andykosela.com> wrote: > On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote: >> >> On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote: >> >> <snip> >> >> >>> Everything has gotten more complicated. Some of the complexity >>> involves reasonable tradeoffs (the move toward replacing binary >>> interfaces with readable text where space and time are nowhere >>> near critical, like the /proc and /sys trees in modern Linux). >> <snip> >> >> To digress from the main topic, I realize that's just one example, but >> here's a counterpoint to it: >> >> We in Solaris designed /proc as a tool for developers to build innovative >> solutions, not an end-user interface. The Linux community believes that 'cat >> /proc/self/maps' is the best user interface, while we believe that pmap(1) >> is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M) >> and a host of other tools all make use of this same information. It would be >> a waste of time to take binary information in the kernel, convert it to >> text, and then have the userland components all write their own (error >> prone) parsing routines to convert this information back into a custom >> binary form. Plus, we can change the options and output format of pmap >> without breaking other applications that depend on the contents of /proc. >> >> [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc] > > Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1) > and ptrace(2). I am still not too sure if it was the Right Thing(r) > to do though. The decision was more based on the premise that > procfs(4) was neglected in recent years than on anything else[0]. > > [0] http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-procstat-td4028960.html FreeBSD also chose to export most nuggets of data from the kernel that are covered by /proc in linux via sysctls. This is one reason that /proc suffered atrophy in the system: nothing was really using it. One could debate at length the relative merits of each, but the long-term viability of both in their respective system I think shows more that the parts that people use are made to work, with warts well known and tolerated, rather than any one form being purer than the other. Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/224198f7/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [TUHS] procfs on FreeBSD (WAS: Re: Unix taste) 2014-08-05 2:41 ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela 2014-08-05 3:32 ` Warner Losh @ 2014-08-05 9:48 ` Dario Niedermann 1 sibling, 0 replies; 11+ messages in thread From: Dario Niedermann @ 2014-08-05 9:48 UTC (permalink / raw) Andy Kosela <akosela at andykosela.com> wrote: > Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1) > and ptrace(2). I am still not too sure if it was the Right Thing(r) > to do though. It wasn't, IMO. It's a departure from "everything is a file". A tenet which - if anything - should be more widely embraced, rather than discarded (I'm looking at you, X11 !) In fact, that's a major FreeBSD peeve of mine. -- Dario Niedermann. Also on the Internet at: gopher://retro-net.org/1/dnied/ , http://devio.us/~ndr/ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-08-05 12:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-04 20:21 [TUHS] Unix taste (Re: terminal - just for fun) Norman Wilson 2014-08-04 22:24 ` A. P. Garcia 2014-08-04 22:23 ` [TUHS] /proc - linux vs solaris Larry McVoy 2014-08-04 23:11 ` Larry McVoy 2014-08-05 1:26 ` A. P. Garcia 2014-08-05 11:55 ` A. P. Garcia 2014-08-05 12:06 ` Tim Bradshaw 2014-08-05 12:37 ` Steffen Nurpmeso 2014-08-05 2:41 ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela 2014-08-05 3:32 ` Warner Losh 2014-08-05 9:48 ` [TUHS] procfs on FreeBSD (WAS: Re: Unix taste) Dario Niedermann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).