Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 360 insertions, 0 deletions

diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn
new file mode 100644
index 00000000..e55b0e8e
--- /dev/null
+++ b/open_issues/hurd_101.mdwn
@@ -0,0 +1,360 @@
+[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].)
+
+Not the first time that something like this is proposed...
+
+
+# IRC, freenode, #hurd, 2011-07-25
+
+    [failed GNU/Hurd project]
+    < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many
+      many people who insist on picking a hard task; realizing that indeed it's
+      hard; and going into hiding
+    < antrik> we see that happen every couple of months
+    < cluck> maybe we need a "hurd 101" 
+    < cluck> getting a teacher and setting up a regularly held "class" for hurd
+      noobs
+    < Tekk_> cluck: what would that include?
+    < cluck> explaining core concepts, giving out "homework" (small tasks), etc
+
+[[Anatomy_of_a_Hurd_system]].
+
+    < cluck> that way "the big guys" could focus on the hard stuff and have an
+      army of code monkeys at their disposal to write speced stuff
+    < cluck> (then again this idea would heavily depend on available "teachers"
+      and "students", which, going by gsoc numbers, may not be all that
+      helpful)
+    < Tekk_> cluck: gsoc isn't an accurate indicator
+    < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P
+    < antrik> cluck: we don't need code monkeys... we need hackers
+    < Tekk_`> antrik: code monkeys involve into hackers
+    < Tekk_`> under the right conditions
+    < cluck> antrik: jokes aside some sort of triage system/training ground for
+      newcomers could be helpful
+
+
+# IRC, freenode, #hurd, 2013-01-20
+
+    <zacts> so once I have written my first translators, and really understand
+      that, what kinds of projects would you recommend to an operating
+      systems/hurd newbie.
+    <zacts> I am reading the minix book now as I have it, but I'm waiting on
+      getting the modern operating systems book by the same author.
+    <zacts> I was initially going to start working on minix, but their focus
+      seems to be on embedded, and I want to work on a system that is more
+      general purpose, and I like the philosophy of freedom surrounding the
+      hurd.
+    <zacts> I like how the hurd design allows more freedom for users of the
+      operating system, but I would also like to incorporate ideas from minix
+      on the hurd. mainly, rebootless updates of servers/translators.
+    <neal> then you should study how translators work
+    <neal> how ipc works
+    <neal> and understand exactly what state is stored where
+    <zacts> ok
+
+
+# IRC, freenode, #hurd, 2013-10-12
+
+    <ahungry> Hi all, can anyone expand on
+      https://www.gnu.org/software/hurd/contributing.html - if I proceed with
+      the quick start and have the system running in a virtual image, how do I
+      go from there to being able to start tweaking the source (and recompiling
+      ) in a meaningful way?
+    <ahungry> Would I modify the source, compile within the VM and then what
+      would be the next step to actually test my new changes?
+    <braunr> ahungry: we use debian
+    <braunr> i suggest formatting your changes into patches, importing them
+      into debian packages, rebuilding those packages, and installing them over
+      the upstream ones
+    <ahungry> what about modifications to mach itself?  or say I wanted to try
+      to work on the wifi drives - I would build the translator or module or
+      whatever and just add to the running instance of hurd?
+    <ahungry> s/drives/drivers
+    <braunr> same thing
+    <braunr> although
+    <braunr> during development, it's obviously a bit too expensive to rebuild
+      complete packages each time
+    <braunr> you can use the hurd on top of a gnumach kernel built completely
+      from upstream sources
+    <braunr> you need a few debian patches for the hurd itself
+    <braunr> a lot of them for glibc
+    <braunr> i usually create a temporary local branch with the debian patches
+      i need to make my code run
+    <braunr> and then create the true development branch itself from that one
+    <braunr> drivers are a a dark corner of the hurd
+    <braunr> i wouldn't recommend starting there
+    <braunr> but if you did, yes, you'd write a server to run drivers, and
+      start it
+    <braunr> you'd probably write a translator (which is a special kind of
+      server), yes
+    <ahungry> braunr: thanks for all the info, hittin the sack now but ill have
+      to set up a box and try to contribute 
+
+
+# Documentation
+
+## IRC, freenode, #hurd, 2013-11-04
+
+    <stargater> i think the problem my hurd have not more developers or
+      contubutors is the project idears and management , eg, the most problem
+      is the mach kernel and documatation and the missing subsystem goals
+      (driver, etc)
+    <stargater> no i think you and other have a clue but this is not
+      tranzparent when i read the webpage 
+    <teythoon> well, fwiw I agree, the documentation is lacking
+    <braunr> about what ?
+    <braunr> something that doesn't exist ?
+    <braunr> like smp or a generic device driver framework ?
+    <teythoon> no, high level concepts, design stuff
+    <braunr> what ?
+    <braunr> how come ?
+    <teythoon> not even the gnumach documentation is complete
+    <braunr> for example ?
+    <braunr> see http://www.sceen.net/~rbraun/doc/mach/
+    <braunr> which is my personal collection of docs on mach/hurd
+    <braunr> and it's lacking at least one paper
+    <braunr> well two, since i can't find the original article about the hurd
+      in pdf format
+    <braunr> project ideas are clearly listed in the project ideas page
+    <stargater> braunr: do you think the mach kernel decumatation a compleat?
+      and you think its good documentatition about "how write a drive for mach"
+      and you think a answare is found why dont work smp and why is have no
+      arm, x64 support ?
+    <braunr> stargater:
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/
+    <braunr> the page is even named "project ideas"
+    <braunr> the mach kernel is probably the most documented in the world
+    <braunr> even today
+    <braunr> and if there is no documentation about "how to write drivers for
+      mach", that's because we don't want in kernel drivers any more
+    <braunr> and the state of our driver framework is practically non existent
+    <braunr> it's basically netdde
+    <braunr> partial support for network drivers from linux
+    <braunr> that's all
+    <braunr> we need to improve that
+    <braunr> someone needs to do the job
+    <braunr> noone has for now
+    <braunr> that's all
+    <braunr> why would we document something that doesn't exist ?
+    <braunr> only stupid project managers with no clue about the real world do
+      that
+    <braunr> (or great ones who already know everything there is to know before
+      writing code, but that's rare)
+    <braunr> stargater: the answer about smp, architectures etc.. is the same
+    <stargater> spirit and magic are nice ;-) braunr sorry, that is only my
+      meanig and i will help, so i ask and say what i think. when you say, hurd
+      and mach are good and we on the right way, then its ok for me . i wonder
+      why not more developer help hurd. and i can read and see the project page
+      fro side a first time user/developer
+    <braunr> i didn't say they're good
+    <braunr> they're not, they need to be improved
+    <braunr> clearly
+    <stargater> ok, then sorry
+    <braunr> i wondered about that too, and my conclusion is that people aren't
+      interested that much in system architectures
+    <braunr> and those who are considered the hurd too old to be interesting,
+      and don't learn about it
+    <braunr> consider*
+    <braunr> stargater: why are you interested in the hurd ?
+    <braunr> that's a question everyone intending to work on it should ask
+    <stargater> the spirit of free software and new and other operation system,
+      with focus to make good stuff with less code and working code for ever
+      and everone can it used 
+    <braunr> well, if the focus was really to produce good stuff, the hurd
+      wouldn't be so crappy
+    <braunr> it is now, but it wasn't in the past
+    <stargater> a good point whas more documentation in now and in the future,
+      eg, i like the small project http://wiki.osdev.org/ and i like to see
+      more how understanding mach and hurd 
+    <nalaginrut> I love osdev much, it taught me a lot ;-D
+    <braunr> osdev is a great source for beginners
+    <braunr> teythoon: what else did you find lacking ?
+    <teythoon> braunr: in my opinion the learning curve of Hurd development is
+      quite steep at the beginning
+    <teythoon> yes, documentation exists, but it is distributed all over the
+      internets
+    <braunr> teythoon: hm ok
+    <braunr> yes the learning curve is too hard
+    <braunr> that's an entry barrier
+
+
+# IRC, freenode, #hurd, 2014-02-04
+
+[[!tag open_issue_documentation]]
+
+    <bwright> Does the GNU Mach kernel have concepts of capabilities?
+    <braunr> yes
+    <braunr> see ports, port rights and port names
+    <bwright> Does it follow the take grant approch
+    <bwright> approach*
+    <braunr> probably
+    <bwright> Can for example I take an endpoint that I retype from untyped
+      memory and mint it such that it only has read access and pass that to the
+      cspace of another task over ipc.
+    <bwright> Where that read minted cap enforces it may onnly wait on that ep.
+    <braunr> ep ?
+    <braunr> ah
+    <bwright> Endpoint.
+    <braunr> probably
+    <bwright> Alright cool.
+    <braunr> it's a bit too abstract for me to answer reliably
+    <braunr> ports are message queues
+    <braunr> port rights are capabilities to ports
+    <bwright> Not sure exactly how it would be implemented but essentially you
+      would have a guarded page table with 2 levels, 2^pow slots.
+    <braunr> port names are integers referring to port rights
+    <braunr> we don't care about the implementation of page tables
+    <bwright> Each slot contains a kernel object, which in itself may be more
+      page tabels that store more caps.
+    <braunr> it's not l4 :p
+    <braunr> mach is more of a hybrid
+    <bwright> It isn't a page table for memory.
+    <braunr> it manages virtual memory
+    <bwright> Ah ok.
+    <braunr> whatever, we don't care about the implementation
+    <bwright> So if I want to say port an ethernet driver over.
+    <braunr> whether memory or capabilities, mach manages them
+    <bwright> Can I forward the interrupts through to my new process?
+    <braunr> yes
+    <braunr> it has been implemented for netdde
+    <braunr> these are debian specific patches for the time being though
+    <bwright> Great, and shared memory set ups are all nice and dandy.
+    <braunr> yes, the mach vm takes care of that
+    <bwright> Can I forward page faults?
+    <bwright> Or does mach actually handle the faults?
+    <bwright> (Sorry for so many questions just comparing what I know from my
+      microkernel knowledge to mach and gnu mach)
+    <braunr> mach handles them but translates them to requests to userspace
+      pagers
+    <bwright> (Still have a mach paper to read)
+    <bwright> Alright that sounds sane.
+    <bwright> Does GNU mach have benchmarks on its IPC times?
+    <braunr> no but expect them to suck :)
+    <bwright> Isn't it fixable though?
+    <braunr> mach ipc is known to be extremely heavy in comparison with modern
+      l4-like kernels
+    <braunr> not easily
+    <bwright> Yeah so I know that IPC is an issue but never dug into why it is
+      bad on Mach.
+    <bwright> So what design decision really screwed up IPC speed?
+    <braunr> for one because they're completely async, and also because they
+      were designed for network clusters, meaning data is typed inside messages
+    <bwright> Oh weird
+    <bwright> So how is type marshalled in the message?
+    <braunr> in its own field
+    <braunr> messages have their own header
+    <braunr> and each data field inside has its own header
+    <bwright> Oh ok, so I can see this being heavy.
+    <bwright> So the big advantage is for RPC
+    <bwright> It would make things nice in that case.
+    <bwright> Is it possible to send an IPC without the guff though?
+    <bwright> Or would this break the model mach is trying to achieve?
+    <bwright> I am assuming Mach wanted something where you couldn't tell if a
+      process was local or not.
+    <bwright> So I am assuming then that IPC is costly for system calls from a
+      user process.
+    <bwright> You have some sort of blocking wait on the call to the service
+      that dispatches the syscall.
+    <bwright> I am assuming the current variants of GNU/Hurd run on glibc.
+    <bwright> It would be interesting to possibly replace that with UlibC or do
+      a full port of the FlexSC exceptionless system calls.
+    <bwright> Could get rid of some of the bottlenecks in hurd assuming it is
+      very IPC heavy.
+    <bwright> And that won't break the async model.
+    <bwright> Actually should be simpler if it is already designed for that.
+    <bwright> But would break the "distributed" vibe unless you had the faults
+      to those shared pages hit a page faulter that sent them over the network
+      on write.
+    <bwright> </end probably stupid ideas>
+    <kilobug> bwright: a lot of POSIX compatibility is handled by the glibc,
+      "porting" another libc to the Hurd will be a titanic task
+    <bwright> In theory exceptionless system calls work fine on glibc, it is
+      just harder to get them working.
+    <bwright> has not been done or was not explored in the paper.
+    <bwright> Something about it having a few too many annoying assumptions.
+    <bwright> Would be interesting to run some benchmarks on hurd and figure
+      out where the bottlenecks really are.
+    <bwright> At least for an exercise in writing good benchmarks :P
+    <bwright> I have a paper on the design of hurd I should read actually.
+    <bwright> After I get through this l4 ref man.
+    <braunr> the main bottleneck is scalability
+    <braunr> there are a lot of global locks
+    <braunr> and servers are prone to spawning lots of threads
+    <braunr> because, despite the fact mach provides async ipc, the hurd mostly
+      uses sync ipc
+    <braunr> so the way to handle async notifications is to receive messages
+      and spawn threads as needed
+    <bwright> Lets take a senario
+    <braunr> beyond that, core algorithms such as scanning pages in pagers, are
+      suboptimal
+    <bwright> I want to get a file and send it across the network.
+    <bwright> How many copies of the data occur?
+    <braunr> define send
+    <braunr> ouch :)
+    <braunr> disk drivers are currently in the kernel
+    <bwright> I read a block from disk, I pass this to my file system it passes
+      it to the app and it sends to the lwip or whatever interface then out the
+      ethernet card.
+    <braunr> and "block device drivers" in userspace (storeio) are able to
+      redirect file system servers directly to those in kernel drivers
+    <braunr> so
+    <braunr> kernel -> fs -> client -> pfinet -> netdde (user space network
+      drivers on debian hurd)
+    <bwright> Alright. Hopefully each arrow is not a copy :p
+    <braunr> it is
+    <bwright> My currently multiserver does this same thing with zero copy.
+    <braunr> because buffers are usually small
+    <braunr> yes but zero copy requires some care
+    <bwright> Which is possible.
+    <braunr> and usually, posix clients don't care about that
+    <bwright> Yes it requires a lot of care.
+    <bwright> POSIX ruins this
+    <bwright> Absolutely.
+    <braunr> they assume read/write copy data, or that the kernel is directly
+      able to access data
+    <bwright> But there are some things you can take care with
+    <bwright> And not break posix and still have this work.
+    <braunr> pfinet handles ethernet packets one at a time, and 1500 isn't
+      worth zero copying
+    <bwright> This depends though right?
+    <braunr> i'm not saying it's not possible
+    <braunr> i'm saying most often, there are copies
+    <bwright> So if I have high throughput I can load up lots of packets and
+      the data section can then be sectioned with scatter gather 
+    <braunr> again, the current interface doesn't provide that
+    <bwright> Alright yeah that is what I expected which is fine.
+    <bwright> It will be POSIX compliant which is the main goal.
+    <braunr> not really scatter gather here but rather segment offloading for
+      example
+    <braunr> ah you're working on something like that too :)
+    <bwright> Yeah I am an intern :)
+    <bwright> Have it mostly working, just lots of pain.
+    <bwright> Have you read the netmap paper?
+    <bwright> Really interesting.
+    <braunr> not sure i have
+    <braunr> unless it has another full name
+    <bwright> 14.86 million packets per second out of the ethernet card :p
+    <bwright> SMOKES everything else.
+    <bwright> Implemented in Linux and FreeBSD now.
+    <bwright> Packets are UDP 1 byte MTU I think
+    <bwright> 1 byte data *
+    <bwright> To be correct :p
+    <braunr> right, i see
+    <bwright> Break posix again
+    <bwright> "More Extend"
+    <braunr> i've actually worked on a proprietary implementation of such a
+      thing where i'm currently working
+    <bwright> Bloody useful for high frequency trading etc.
+    <bwright> Final year as an undergraduate this year doing my thesis which
+      should be fun, going to be something OS hopefully.
+    <bwright> Very fun field lots of weird and crazy problems.