IRC channel logs


back to list of logs

***mbanck_ is now known as mbanck
<m4t3>How far is the Hurd 64bit port?
<youpi>the kernel boots, the first process does some system calls
<m4t3>Thank you. I am of the opinion that we have to aggressively pursue this port, 64bit has a large user base.
<m4t3>We need more people trying and testing the Hurd both in VMs and baremetal (let's give YouTube runboxers more content), moreso we need new eyes, young blood and old wisdom.
<curiosa>m4t3 I think we need a lot of marketing for that
<curiosa>one idea I had is that maybe the hurd should make an ecosystem
<curiosa>something like PyPI or CPAN, but for hurd servers
<curiosa>there are things you can find on the net that are not part of the main hurd, such as two audio drivers
<curiosa>an unionfs
<curiosa>that feels like abandonware from the outside
<curiosa>I have a concern on how much hurd servers are meant to be composed
<curiosa>but if that was a possibilty, for instance by having servers using other servers under the hood
<curiosa>you see how much an ecosystem could provide a cooperative boost to the hurd
<curiosa>another thing would be to break compatibility with POSIX
<curiosa>that would be positive
<curiosa>at least from the marketing standpoint
<curiosa>for instance a windowing system that is not wayland or X11
<curiosa>but uses Mach RPCs for mode settings and resource allocation
<curiosa>a console that includes tmux support
<curiosa>I am not sure how much people really care about 64bit; SMP seems a more powerful abstraction performanewise
<youpi>the console is already tmuxified
<youpi>you can connect several console clients to it
<curiosa>but a 64bit port would be a great marketing boost
<youpi>we do care about 64bit for year-2048-ness, and addressing space, we do have problems with building large packages
<youpi>SMP is an important thing too
<curiosa>youpi I was thinking that the console could also support remote multiplexing through ssh
<youpi>both flock together actually: they'll both be easier once we get rid of the linux code from gnumach
<youpi>curiosa: for the ssh case you can use tmux
<youpi>there is no need to reinvent it
<curiosa>just integrate it better, there are hooks for terminal emilators in tmux
<curiosa>like imagining opening ssh, doing tmux -CC to enter in control mode and having the console directly integrate with the remote tmux
<curiosa>by the way these kind of stuff could be implemented in an ecosystem where everyone could contribute, that what I meant by ecosystem
<scm>Hi all, I'm looking forward to installing Hurd and helping out with documentation.
<curiosa>youpi: what I really meant was not specific to the kernel or to the console; there might be many other things
<curiosa>reinventing wheels could be a good strategy since it allows people to be very ideosynchratic
<curiosa>if they are allowed to be dirty of course, hence an ecosystem
<youpi>reinventing wheels also means having to mainting them
<curiosa>hence an ecosystem
<curiosa>I was wondering about composability of translators
<curiosa>if things get composable
<curiosa>then if one break the other break
<curiosa>this seems like a loss of time, but in fact allows other to take care of maintenaince of code they didn't write
<curiosa>of course there is no reason why translators wouldn't be as composalbe as software libraries
<curiosa>is __GNU__ is the correct define for hurd specific code?
<curiosa>do linux define that?
<curiosa>ok thanks
<curiosa>is BSD defined on hurd?
<youpi>because it provides the BSD interface
<curiosa>it doesn't provide arc4random_buf apparently
<curiosa>easy fix
<curiosa>What would be the ideomatic way in the Hurd to get the executable path from a program?
<curiosa>readlink /proc/curproc/exe ?
<youpi>if you look for a very hurdish way you have proc_get_exe
<youpi>but otherwise reading proc will work, yes
<curiosa>youpi thanks, will #include <hurd.h> suffice to call that RPC?
<curiosa>ok, gonna use proc
<curiosa>I saw it
<curiosa>proc_get_exe(getproc(), getpid(), buf);
<curiosa>works, but how this avoids buffer overflows?
<curiosa>I was expecting buf to be char **, but instead it is char *
<youpi>it's not char*, it's string_t
<youpi>which is a char[1024] :/
<curiosa>ok, sorry for the confusion
<curiosa>I got SEGFAULT and I didnt know why
<curiosa>would have been nice if the compiler warned
<curiosa>there is /* XXX */ next to string_t definition, does it means that it will eventually change?
<youpi>we'd like to avoid hardcoded 1024 yes
<youpi>when you get a segfault, use gdb to know where exactly that happens
<curiosa>but how do you avoid to hardcode 1024 if you don't pass a size parameter in the RPC?
<youpi>normally the compiler should have warned about the poniter incoherency
<youpi>did you pass -Wall -Wextra ?
<youpi>by changing the RPC etc.
<youpi>thus the "XXX" that has been there for long
<curiosa>maybe they were imagining there would be a structured string type of the kind (size_t len, buffer), in any case introducing that would break the rpc
<curiosa>so still changing the RPC etc.