rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 360 deletions

diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn
deleted file mode 100644
index e55b0e8e..00000000
--- a/open_issues/hurd_101.mdwn
+++ /dev/null
@@ -1,360 +0,0 @@
-[[!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.