Haiku Admin Meeting 2007-07-02:
- Discussion about WalterCon planning. Things are moving along.
- The existence of a project called RadiantOS which claims to eventaully be a "distro" based on Haiku was mentioned.
- There was some discussion about the status of running GCC in Haiku:
Haiku might be close to self-hosting capability (able to build itself).
It was mentioned that once Haiku can self-host it's probably time for an official alpha release.
Haiku Admin Meeting 2007-07-09:
- There was some discussion about AGG and the recent buzz about it on OSNews and other places.
- The Admin Team Gathering was discussed some more.
- Some WalterCon issues were discussed:
The registration module on the WalterCon website appears to be broken.
There is a need for more presenters.- Some progress is being made on the x86-64 build-environment issues.
- The ability for Haiku to self-host was discussed further:
Axel and Ingo will take a look at the VM issues.- GSoC progress was discussed:
Lots of good results from the participants are already surfacing.
End of July 2, 2007 and July 9, 2007 meetings.I would like to remind readers that any official discussion about the decisions made by the Haiku Admins should be directed to the General Mailing List. Any mistakes in this summary may be posted in the comments if desired or you may use my contact page.Even though I had some private issues this week, all is going well with the PackageInstall. In its current form it is able to properly install all 3 test BeOS packages I tried on it, creating files and directories along with their data and attributes without flaw. So, what’s left to do right now?
For the API Documentation team I’ve prepared an overview of the messaging functions in the Application Kit, mind map style. This image should be the guide to writing the actual API documentation.
Please redirect comments on the technical content to the haiku-development list. They are highly appreciated!
A couple of articles I just read (here and its rebuttal) are written by Linux users about why Linux is the best and how to get a regular person (hereafter referred to as Joe User) to start using Linux. To save you the time of reading the two articles, the first is entitled “Understanding the Common User: Everything should be as simple as it is, " by Keyto. The article is partly about how a Common User thinks, but primarily that quite a lot of the problem with Linux is the current users – geeks who have trouble relating to Joe at Joe’s level of expertise instead of the geek’s level. The rebuttal “Get Real or How NOT To Convert Your Grandma to Linux,” by Karol Trojanowski, advises that Linux users shouldn’t try to “convert” everyone and why. A quote from the article describes Linux perfectly: “A wand does magic in a wizard’s hand. Otherwise, it’s just a stick.” All too true. Many of the problems that Linux advocates face are the same ones that BeOS proponents struggle with. The first step to effective persuasion is understanding the audience, so who exactly is Joe User, anyway?
Haiku Admin Meeting 2007-06-18:
- Discussion about some "missing" articles on the new website - specifically old newsletters. Also desired is a way to make them easier to locate.
- Mention of the continual "browser for Haiku" topic that pops up in the mailing list and elsewhere. An official decision should be discussed and published. It may be still too early to fully decide on a direction.
- More discussion took place about a potential physical "admin gathering" in the near future.
Haiku Admin Meeting 2007-06-26:
- Darkwyrm has been working on the WalterCon 2007 details including some content. Some ideas were discussed.
End of June 18, 2007 and June 26, 2007 meetings.I would like to remind readers that any official discussion about the decisions made by the Haiku Admins should be directed to the General Mailing List. Any mistakes in this summary may be posted in the comments if desired or you may use my contact page.Haiku’s network stack follows a top-down approach with clear boundaries, pure object oriented design. However, TCP/IP protocol stack was designed more than 30 years ago with different idea in mind. It’s mostly speed, fast processing and stability that designers were looking for back then. That’s why many boundaries in the TCP/IP protocol suite design are blurred somehow.
Basic hierarchy is established. Datalink layer protocol (Ethernet, PPP, etc.) is followed by a Network layer protocol (IP), which is followed by a Transport layer protocol (TCP, UDP, SCTP, etc). Those protocol often need to interact besides the limits of data transfer between two endpoints. Congestion control, error reporting, information exchange is needed. And with one exception (TCP) protocols lack that functionality.
Just to keep those of you interested updated, after discussing it with both my mentor and Michael Lotz, and after a very quick chat with Francois Revol, I am going to add isochronous support to both the USBKit and usb_raw driver. Meanwhile Francois, if time is on his side, should add isochronous support to his user space quickcam driver (see src/add-ons/media/media-add-ons/usb_webcam/). This way I can test my previous patches and perhaps everyone can start using his logitech quickcam with Haiku by using codycam. I don’t know though for sure, what product id are supported.
For those of you who are not following the haiku-commit mailing list, I’ve added the isochronous support to the UHCI driver. I’m working on a quickcam driver to test the code, but if someone of you out there, already have some very simply driver, that needs isochronous support, please contact me and help me with the testing.
The sooner I’m done with the testing, the sooner I’ll move on to the OHCI driver. ;-)
(Or: knitting a delicate fabric, part II: sewing it all together)
(Or: Right, Joker, the underwear might be on the outside, but I get to drive the Batmobile!)
(Or: I just had to say something about Batman and the Batmobile. Couldn’t help it.)
Cool, now we have a space- and time-efficient data structure (which is nothing more than a nice structure to handle non-overlapping numeric ranges) we can use to implement the simplified stride scheduling thing I’ve been discussing ou the previous posts, which will remain small most of the time, and won’t change its shape like mad, so it’s also very gentle on the CPU cache. Not only that, but the same effects hold for any trees, shall we decide that red-black trees aren’t adequate and set ourselves to use splay trees, AA trees, AVL trees, Huffman trees, unbalanced binary trees (please: no.), whatever. So far we took care of the (not any more) skewed proportions due to randomness (by using strides), the mapping of “tickets” to tasks (by using trees to store the queues, “indexes” as the tickets, offsets to simulate “special” tickets, and lazy evaluation to efficiently implement offset propagation to upper queues), and the order of complexity (by using the queues as the node elements of the tree, where the key is base priority times number of threads in that queue).
(Or: knitting a delicate fabric, part I: the wool[1])
I sincerely hope you've read the disclaimer by now, but I guess I'd better link to it anyway :) Thanks.
I spent the better part of the last post explaining how simple strides would yield an approximation of the ideal shuffling of tickets. What I didn’t explain, however, was why the hell am I insisting on using tickets when strides/passes avoids those issues completely.
Well, the thing is, I didn’t ditch my previous attempt completely. It had flaws, but there were some gems there as well. I don’t know a single programmer who can’t recognise it’s possible to find sound ideas and really clever excerpts of code even when, on the whole, the code was crap.
(Yes, programmers and software architects are a proud bunch of people.)
And tickets are making a comeback, but in a very different context.
Anyway, suppose we’re starting with a clean slate, and all we have so far are the tasks and their respective priorities. Now let’s scribble a little in that slate :)
