Update FreeBSD build instructions

* Fix table layout

* Fix slash

content/articles/2015-02-05_building_haiku_mac_os_x_1010_yosemite.html

@@ -97,7 +97,7 @@ You should get:
 Configure a GCC 2.95 Hybrid, from a non-Haiku platform
 <pre class="terminal">mkdir /Volumes/Haiku/haiku/generated
 cd /Volumes/Haiku/haiku/generated
-../configure --use-xattr --build-cross-tools x86_gcc2 ../../buildtools/ --build-cross-tools x86</pre>
+../configure --use-xattr --cross-tools-source ../../buildtools/ --build-cross-tools x86_gcc2 --build-cross-tools x86</pre>
 <code>./configure</code> has some more options: use <code>./configure --help</code> to list them.
 After some time, you should get:
 <pre class="terminal">binutils and gcc for cross compilation have been built successfully!</pre>

content/blog/apl/2020-11-16_haikudepot_better_icons.md

@@ -0,0 +1,65 @@
++++
+type = "blog"
+title = "Haiku Depot and Better Icon Handling"
+author = "apl"
+date = "2020-11-17 12:00:00+12:00"
+tags = ["haiku", "haikudepot", "icon", "tar"]
++++
+
+HaikuDepot displays icons through a number of areas of its user interface.  Early in the history of the Haiku packaging system, there were very few packages and very few icons.  HaikuDepot started off by downloading each individually from HaikuDepotServer.
+
+## Download as Tar then Unpack
+
+Downloading each icon file individually was fine for a while, but as the package and hence icon count grew it became necessary to rework this system.  HaikuDepotServer later provided the icons as a compressed tar-ball containing all of the icons.  You can [download](https://depot.haiku-os.org/__pkgicon/all.tar.gz) this yourself.  The tar-ball is unpacked on the Haiku computer into a directory and then the HaikuDepot application reads the individual files from the local disk system.
+
+![Splitting the Tar](/files/blog/apl/haikudepot_better_icons/split-asbuilt.png)
+
+The tar-ball also contains an `info.json` file that carries meta-data about the tar-ball payload.  Specifically this contains timestamp information that can be used to ensure that the cached icons are up to date in comparison with the data on the server.
+
+Handling the icon transfer in this way made a huge improvement to the speed at which HaikuDepot launched. 
+
+## Download as Tar and Use Directly
+
+At the time of writing there are around 3000 icons in HaikuDepotServer and the unpacking of the tar-ball and use of this now larger number of icons has lead to a few problems.
+
+* The unpacking of the icons is time-consuming because HaikuDepot has to create a large number of files.
+* The updating of the icons is time-consuming because HaikuDepot also has to delete all those files to bring new ones in and then create an updated set of files again.
+* The reading of all those files as images at startup can be time consuming.
+* Holding all those images in memory consumes a significant quantity of memory.
+
+For this reason a new approach has been recently implemented on the HaikuDepot side.  Instead of unpacking the tar-ball, the tar-ball is instead downloaded, decompressed and retained.
+
+![Uncompressed Tar](/files/blog/apl/haikudepot_better_icons/to-uncompressed-tar.png)
+
+After this change, for HaikuDepot to update the icons, a new tar-ball need only be obtained from the server, decompressed and then copied over the top of the old one.  This is quick and easy.
+
+Within the tar ball each of the file resources is at a specific offset within the file.  This diagram shows the tar-ball with the icon files for a ficticious package with name `hello`.
+
+![Tar Positions](/files/blog/apl/haikudepot_better_icons/tar-file-map.png)
+
+By knowing the offset it is possible to later 'seek' to that position, read the tar-header at that location and then read the icon data that follows the header.  At launch time, HaikuDepot scans the tar-ball to find packages' icon files.  As it finds each icon file, it maintains a map of the package name + icon type to the offset where it found the icon data in the tar-ball.
+
+It is quite surprising how fast this works at launch time as it rummages through the tar-ball.  HaikuDepot is also able to read the `info.json` file out of the tar in a similar way -- by scanning the tar-ball instead of unpacking it to a separate file.
+
+## Icon Cache
+
+There is still the problem of the icons all being loaded at once as HaikuDepot starts.  Better would be for HaikuDepot to load the icons as it requires them and to allow those icons which are no longer required to be released from memory.
+
+To achieve this, an least recently used cache is employed.  The name of this structure is often abbreviated to the term "LRU cache".  At the moment that HaikuDepot asks for a package icon, the cache is queried;
+
+* If it is already in the cache then it is returned immediately.
+* Otherwise, if the cache is already full, the icon that was least recent used is dropped from the cache and the new icon is loaded in from the tar-ball and returned for use by HaikuDepot.
+
+## LRU Cache Details
+
+You can find the implementation of the LRU cache in the aptly named `LRUCache.h` file.  How does it work in the context of the icons?
+
+The LRU cache has a map that maps the packages' names to nodes.  The nodes form their own secondary structure which is a double linked list.  The links provide an older and newer link from each node so that it is possible to have an ordering on the items in the map based on when an icon was last used.  Each node also has the key repeated and the icon value.
+
+ ![LRU Cache](/files/blog/apl/haikudepot_better_icons/lru-map.png)
+
+Adding an item to the cache means adding it to the map as well making it the newest item in the linked list.  When the cache is full and an item needs to be evicted to make space, it is an easy job to identify the oldest item and to remove it quickly.  When an item is obtained from the map, that node must then be detached and re-added at the top of the linked list so that it is the newest one.
+
+## Outcomes
+
+Now Haiku is able to update faster, starts faster and uses less memory as it runs.

content/blog/bitigchi/2020-09-06-haiku_monthly_activity_report_august_2020.md

@@ -0,0 +1,89 @@
++++
+type = "blog"
+title = "Haiku Activity Report - August 2020"
+author = "bitigchi"
+date = "2020-09-06 13:00:00+03:00"
+tags = ["monthly activity report"]
++++
+
+Welcome to the Haiku Monthly Activity Report for August 2020. This report covers revisions from hrev54480 to hrev54538.
+
+This month is not active as the last one, but we have exciting improvements in the pipeline, since GSOC 2020 is coming to an end, and our developers are working hard to review GSOC projects at a fast pace.
+
+## Applications
+
+Humdinger improved accessibility on WebPositive by adding a missing tooltip on Settings window.
+
+PulkoMandy and nielx worked on making the Installer more reliable by refining CopyEngine and post-install scripts.
+
+PulkoMandy worked on fixing Pulse issues, now it is scales nicely on modern systems. Previosly, the CPU image was not readable due to bitmap issues. PulkoMandy also improved battery detection for PowerStatus.
+
+PulkoMandy also contributed some nice interface fixes to Icon-o-Matic, it uses more native Haiku widgets, and supports longer filenames.
+
+## arm
+
+kallisti5 continued working on making Haiku working under arm architecture. Currently Haiku is crashing early in the boot process, and it is being investigated.
+
+## Deskbar
+
+John Scipione has re-implemented the old vertical Deskbar mini mode. This version was deprecated in favor of the new horizontal mini mode, which uses only a tab-height of space. With this addition, it is now possible to use Deskbar in 4 different modes:
+
+- Default mode
+- Horizontal mini mode
+- Vertical mini mode
+- Expanded mode
+
+## Drivers
+
+Michael Lotz continued working on audio drivers. Specifically:
+
+- ac97/es1370 audio driver
+- ac97/auich audio driver
+- multi_audio buffer keeping has been improved
+
+## ffmpeg
+
+PulkoMandy has improved ffmpeg support in Haiku, fixing multiple memory leaks, asserts, and deleting unnecessary code.
+
+## GSOC 2020
+
+Following students wrapped up their work on their respective areas:
+
+- Preetpal Kaur, worked on improving input devices support, including Joysticks, tablets, pens, and multiple mice
+- leorize, worked on improving Haiku networking code, which will lead to faster page loads in WebPositive and better communication in other networking tasks
+- Cruxbox, worked on adding XFS file system read support to Haiku
+- SuhelMehta, worked on adding UFS2 file system read support to Haiku
+
+## Kernel
+
+Michael Lotz continued improving the Haiku kernel, fixing exception handlings, security issues, and improving address space support, allowing more than 32TB.
+
+## m68k
+
+mmu_man improved m68k boot loader support, contributed some build fixes and refactoring, so that it can fit in a boot floppy.
+
+## POSIX
+
+rofl0r has fixed the prototype of gethostbyaddr to be more in-line with FreeBSD and Linux.
+
+## RISC-V
+
+kallisti5 continued working on the RISC-V architecture. The initial work on an EFI loader is complete, and u-boot is working.
+
+## System Kits
+
+PulkoMandy has contributed a fix that allows creating a strings catalog just with a MIME-type, there is no need for a separate entry_ref from now on. This will allow localising strings that are not linked to an application or library.
+
+## Tracker
+
+PulkoMandy fixed a resizing issue on Tracker info windows, making it possible to resize info windows without visual glitches.
+
+## Translators
+
+PulkoMandy fixed a locking issue on TranslatorRoster, helping avoid deadlocks if be_app is not yet running.
+
+If you would like to try out these changes right away, grab a copy of the latest [nightlies](https://download.haiku-os.org) and give it a go!
+
+Haiku Project always welcomes new faces. If you are a developer, sysadmin, designer, or a writer, we will always appreciate your support. Come meet us at the [Freenode #haiku IRC channel](irc://chat.freenode.net/haiku),  [forums](https://discuss.haiku-os.org) or introduce yourself in the [Haiku mailing list](https://www.freelists.org/list/haiku).
+
+See you next month!

content/blog/bitigchi/2020-10-01-haiku_monthly_activity_report_september_2020.md

@@ -0,0 +1,98 @@
++++
+type = "blog"
+title = "Haiku Activity Report - September 2020"
+author = "bitigchi"
+date = "2020-10-01 13:00:00+03:00"
+tags = ["monthly activity report"]
++++
+
+Welcome to the Haiku Monthly Activity Report for September 2020. This report covers revisions from hrev54539 to hrev54608.
+
+## System Sounds Contest
+
+We've started a contest for the system sounds, and currently it's ongoing. For more details, see the [contest post](https://www.haiku-os.org/news/2020-09-11-system-sound-contest/).
+
+## Applications
+
+AlwaysLivid improved the after-install UX via a bunch of Installer and FirstBootPrompt fixes. Now it is possible to exit the FirstBootPrompt to Desktop without having to restart the system.
+
+AlwaysLivid added Mail auto-configure data for mailbox.org and riseup.net.
+
+bitigchi fixed the redundant reboot confirmation in SoftwareUpdater.
+
+Pascal Abresch made TeamMonitor and AboutSystem compliant to the system colours; previously the text colours would not react properly to dark system themes.
+
+PulkoMandy fixed various issues with MediaPlayer and ffmpeg implementation that caused high CPU usage and problems with seeking audio files with cover art.
+
+Murai Takashi made some code cleanups in various system parts.
+
+syedsouban and bitigchi implemented custom search engine shortcuts in WebPositive. Currently following shortcuts are supported:
+
+- Google (g)
+- Bing (b)
+- Wikipedia (w)
+- DuckDuckGo (d)
+- Baidu (a)
+- Yandex (y)
+- Ecosia (e)
+- Qwant (q)
+
+## Compatibility
+
+CodeForEvolution implemented the `qsort_r` function.
+
+## Documentation
+
+John Scipione improved the documentation for BMessage and AppKit.
+
+nielx implemented layout customisations for the Doxygen stylesheet.
+
+## File Systems
+
+brjhaiku implemented the initial methods required for btrfs write support. This was originally introduced during GSOC 2019 program, and still being merged gradually.
+
+## Kernel
+
+Jerome Duval implemented support for more CPU power modes and functions that allows the system to use the CPU power more efficiently. This fixed an issue where on some hardware the system clock speed was stuck at 1.5 GHz, and improved performance on other systems.
+
+## Package Management
+
+Andrew Lindesay fixed a crash in HaikuDepot whilst synchronising package metadata, also greatly improved icon caching, therefore speeding up the sync process during application start and memory consumption.
+
+## Preferences
+
+Preetpal Kaur's GSOC project work on Input preferences panel has been merged, and she continues to work on final polishing and bug fixes. Thanks to her work, now it's possible to have different settings for each different mouse.
+
+Preetpal will be continuing working on Input preferences and other Haiku things during her industrial training for the next 3 months.
+
+## POSIX
+
+rofl0r has fixed the prototype of gethostbyaddr to be more in-line with FreeBSD and Linux.
+
+## RISC-V
+
+kallisti5 added u-boot support for RISC-V.
+
+## System Kits
+
+John Scipione fixed a regression that prevented character drawing when a tab is inserted.
+
+Pascal Abresch implemented enabling adding custom user TLS certificates.
+
+PulkoMandy implemented creating catalog files from external source files. This will allow localising applications written using any interpreted language.
+
+## System Servers
+
+PulkoMandy implemented support for saving brightness settings when rebooting the system, and polished the code for handling screen brightness.
+
+## System Translators
+
+Gerasim Troeglazov fixed a crash that occurs while displaying `.icns` files.
+
+------
+
+If you would like to try out these changes right away, grab a copy of the latest [nightlies](https://download.haiku-os.org) and give it a go!
+
+The Haiku Project always welcomes new faces. If you are a developer, sysadmin, designer, or a writer, we'd appreciate your support. Come meet us at the [Freenode #haiku IRC channel](irc://chat.freenode.net/haiku),  [forums](https://discuss.haiku-os.org) or introduce yourself on the [Haiku mailing list](https://www.freelists.org/list/haiku).
+
+See you next month!

content/blog/bitigchi/_index.md

@@ -0,0 +1,5 @@
++++
+type = "blog_index"
+author = "bitigchi"
+title = "bitigchi's blog"
++++

content/blog/cruxbox/2020-06-06_gsoc_2020_xfs_project_update.md

@@ -2,7 +2,7 @@
 type = "blog"
 title = "GSoC 2020 Project Update: XFS"
 author = "CruxBox"
-date = "2020-06-06 20:45:56+05:30"
+date = "2020-06-07 20:45:56+05:30"
 tags = ["haiku", "software", "gsoc", "gsoc2020", "file system"]
 +++
 
@@ -12,7 +12,7 @@ It's been exactly a month since my last post. Sorry for not posting much!
 ---
 
 Work done so far:
-You can check for the patches here: https://review.haiku-os.org/q/owner:shubhambhagat111%2540yahoo.com
+You can check for the patches here: https://review.haiku-os.org/q/hashtag:gsoc2020+owner:shubhambhagat111%2540yahoo.com
 
 But in short this is what is done,
 

content/blog/cruxbox/2020-08-06_gsoc_2020_project_xfs_project_update.md

@@ -0,0 +1,58 @@
++++
+type = "blog"
+title = "GSoC 2020 Project Update: XFS"
+author = "CruxBox"
+date = "2020-08-11 17:58:00+05:30"
+tags = ["haiku", "software", "gsoc", "gsoc2020", "file system"]
++++
+
+Hello there!
+There is quite a lot to share about the work done this month.
+
+---
+
+## Work done so far:
+
+You can check for the patches here: https://review.haiku-os.org/q/hashtag:gsoc2020+owner:shubhambhagat111%2540yahoo.com
+In short: All directory work is done. This includes ShortForm Directories, Block Directories, Leaf Directories, Node Directories and B+Tree based Directories.
+
+Detailed view at the work:  
+(Some context: Leaf entries containt hash values of a directory entry name and also the address of that entry. We use this for fast lookups.)  
+
+1) Leaf Directories:  
+
+When a directory block (directory blocks are larger than normal file system blocks) isn't enough to hold all directory entries and the leaf entries within a single directory block, the block expands and now the directory entries and leaf entries stay entirely in different directory blocks. There could be many directory blocks but there is only a single leaf block.  
+
+All block mappings are present within the inode itself. I made sure to use binary search (with a modified predicate, of course) within the leaf block to reduce the time complexity of Lookup(). It was interesting to see how different structures play here. The original docs were quite helpful.  
+
+2) Node Directories:  
+
+When a single leaf directory block can't hold all the hashes and address of all the directory entries, we need to expand it. Now Lookup becomes tricky here. There is another block which tells which tells the last hash value in every leaf block. And since the leaf block contains the entries sorted based on hash value, the task was to utilize this and find the right leaf block for our desired hash value so that we could go there, get the address and then get information about this desired entry.  
+
+The docs were decent but I think understanding why these structures are placed the way they are was what helped my complete this task. In my test I was able to store and output around 1005 entries.  
+
+3) B+Tree Directories:  
+
+This is an interesting one. I think the docs just showed the structure and it wasn't informative. I have already encountered B+Trees in past so it wasn't a problem, but the layout wasn't given very well. I ended up using xfs_db, a debugging tool for an xfs image, a lot as it also comes with a hex editor. While talking to people at #xfs I figured out the structure after understanding their findings. I quickly implemented some functions and set the ground work. Soon we had a working GetNext() function.  
+
+The hook that I think required more work was Lookup. The brute force solution to this problem was already quite complicated. I spoke to my mentor and added some optimizations which I think will definitely help save quite a lot of reads from the disk.  
+
+I basically save all the blocks while going down the tree and hope that these blocks will be the ones (or at least some of them) that will be required when I try to go down the tree again. There is one more thing I added which I think will improve efficiency: saved 2 different paths. That is one path will save blocks when looking for a Leaf, and one path when looking for a directory entry. This is because, XFS B+Trees are more spread out than they are deep. And the directory entries will probably be far away from the leaf entries in most cases.  
+
+I hope that makes sense? I am here to answer to questions if you have any. I was able to test 20,000 entries and the code works well. But I want to test more.  
+
+---
+
+## Next Steps:
+
+Files are yet to be done but I understand the structure in which they are laid out and am positive that it can be done. But for that I first need to understand how the kernel interface works for it.  
+
+I have tested the B+Trees directories with 20,000 entries. I want to test 100,000 entries or more now. It will help me create all potential scenarios and debug my code accordingly. But due to the limitations of my own system it's taking way too long to create these directories. I will have to give it a few hours perhaps.  
+
+---
+
+## What I learnt:
+
+I enjoyed coming up with basic algorithms and then making more and more optimizations over them. It has been a great learning experience so far!  
+
+Good day!  

content/blog/cruxbox/2020-08-30_gsoc_2020_project_xfs_project_final_report.md

@@ -0,0 +1,61 @@
++++
+type = "blog"
+title = "GSoC 2020 Final Report: XFS File System"
+author = "CruxBox"
+date = "2020-08-30 17:58:00+05:30"
+tags = ["haiku", "software", "gsoc", "gsoc2020", "file system"]
++++
+
+Hello there!
+This is the final report on my project which aimed at initiating support for XFS Filesystem on Haiku, by first making a read only driver.  
+
+---
+
+## Work done during the program:
+
+You can check for the patches here: https://review.haiku-os.org/q/hashtag:gsoc2020+owner:shubhambhagat111%2540yahoo.com
+
+All directory and files work is completed and we should be able to read them from a version 4 XFS Filesystem. I've come to realize that we can now even try to read version 5 of XFS now that the ground work has been placed.
+
+I suggest the reader to read the previous blog post to understand the work done for directories. Since, apart for testing, this month involved work mostly pertaining to files.  
+
+Links:
+1) https://www.haiku-os.org/blog/cruxbox/2020-06-06_gsoc_2020_xfs_project_update/
+2) https://www.haiku-os.org/blog/cruxbox/2020-08-06_gsoc_2020_project_xfs_project_update/  
+
+Detailed view at the work:  
+
+1) B+Tree Directories:  
+
+	In the last post I had mentioned that we need to test this more. I am glad I did. I ended up testing 100,000 directory entries and we were reading without any problems.  
+	I then tried reading 200,000 entries and there was a small issue with obtaining the right address to the directory entry. This doesn't seem like a big problem in terms of how much needs to be fixed (maybe only a few lines of code) but the issue is that no one from #xfs could help and the documentation clearly wasn't as accurate. Perhaps, I'll see if I can get other developers to help me out in this (Axel you reading? :P)
+
+2) Extent based files:  
+
+	Files are stored in blocks and each block size is defined in the superblock. The inode, if is extent based, has the mappings to all these blocks. I simply had to read all these mappings, and start reading at the right block based on the offset that was given by the xfs_read() hook. It was pretty straightforward because I had understand the structures pretty well while I was working on the directories.
+
+3) B+Tree based files:
+
+	If the number of mappings increases to an extent that we no longer can store them in an inode, we end up using B+Trees. The leaves of the B+Trees now hold the mappings. So the goal was to simply get to the left most leaf and read all the mappings. We store these maps in a linear data structure, more specifically, an array, and given the small number of mappings (and hence short length of the array) it's okay to search for the right map linearly, which I did. Perhaps I'll implement binary search there (which will take a minute or two) for more efficiency but it really wouldn't show to be honest. But I'll do it anyway because we should if we can.  
+
+Anyway I'll add some screenshots I took while using the xfs_shell in some time. Don't mind the directory names and file content :P!
+
+---
+
+## What's next for me with Haiku?
+
+I definitely intend to explore a lot and try new things. Maybe port Go to Haiku or look at the network stack. There is a lot of work and I am excited to see what I end up doing next.  
+
+I'll have to take some time off given my commitments to university and some other things. But I'll be very much available through mail and in the public channel (just mention me there).  
+
+---
+
+## Program experience:
+
+The project itself was very cool and I got to learn a lot. I feel better about my abilities now than I did a few months back. But that is not only because of my efforts but also because of the amazing mentorship experience.
+
+HyChe, my mentor, was never demanding and motivated me to work at my own pace and take breaks. He suggested a result oriented approach perhaps.
+
+Also, I would like to thank Adrien (PulkoMandy) for his support ever since I joined Haiku. We have had crazy long conversions about many things. Him mentoring me has given me a lot of perspective that I had hoped for from GSoC. I'll always be grateful, friend! :')
+
+

content/blog/dnivra/2014-05-04_gsoc_2014_arm_port_week_1_and_2.html

@@ -79,7 +79,7 @@ index 6cee1a2..f255a36 100644
 <pre class="terminal">
 $ mkdir generated.arm
 $ cd generated.arm
-$ ../configure --build-cross-tools arm ../../buildtools --include-gpl-addons --include-patented-code --use-gcc-pipe -j2 --bootstrap ../../haikuporter/haikuporter ../../haikuports.cross/ ../../haikuports --target-board beagle
+$ ../configure --cross-tools-source ../../buildtools --build-cross-tools arm --include-gpl-addons --include-patented-code --use-gcc-pipe -j2 --bootstrap ../../haikuporter/haikuporter ../../haikuports.cross/ ../../haikuports --target-board beagle
 $ jam -q @bootstrap-raw
 </pre>
 
@@ -89,4 +89,4 @@ $ jam -q @bootstrap-raw
 <li>https://www.freelists.org/post/haiku-gsoc/Booting-the-bootstrap-image-is-it-possible,12</li>
 <li>/guides/building/get-source-git</li>
 <li>http://bb.haikuports.org/haikuports.cross/commits/4287814086470ad7f6869150edf691b843aba6d8/raw/</li>
-</ol>
+</ol>

content/blog/humdinger/2020-08-22_Manipulating_windows_with_hey.md

@@ -0,0 +1,47 @@
++++
+type = "blog"
+title = "Manipulating window look & behaviour with 'hey'"
+author = "humdinger"
+date = "2020-08-22 10:01:02+02:00"
+tags = ["haiku", "scripting", "hey", "look"]
++++
+
+I have an ActivityMonitor replicant showing network receive/send info on the Desktop. I'd also like to have something showing cpu usage. However, a combined cpu usage ActivityMonitor doesn't show individual core usage, and having a graph of all cpus often isn't that informative either, because the 8 doodling lines of my cores are easily confusing. ProcessController's bars are too narrow.   
+Here are both, showing their inadequacy:
+
+![ProcessController to the left, ActivityMonitor to the right](https://www.haiku-os.org/files/blog/humdinger/ProcessController+ActivityMonitor.png)
+
+Pulse (from the Demo folder) in mini-mode has everything I need: adjustable column width and colours. Only downside: The mini-mode isn't replicable, so it'll have to stay in its window. Far from ideal.
+
+## 'hey' to the rescue!
+
+LaunchBox has settings that I need, that Pulse doesn't provide: "*Show on all workspaces*" and a deactivated "*Show window border*". Both settings are scriptable via the "*Workspaces*" and the "*Look*" flags.   
+How to get to the "magic" values to set those, though? By grabbing the values from an accordingly configured LaunchBox:
+
+    hey LaunchBox get Workspaces of Window [0]
+    Reply BMessage(B_REPLY):
+       "result" (B_INT32_TYPE) : -1 (0x-0000001)
+
+Aha: **-1** to be visible on all workspaces
+
+    hey LaunchBox get Look of Window [0]
+    Reply BMessage(B_REPLY):
+       "result" (B_INT32_TYPE) : 20 (0x00000020)
+
+Oho: **20** for a window without borders
+
+One more thing to change: remove Pulse from the list of running apps in the Deskbar, it only wastes precious space there. Unfortunately, coming from a package, Pulse's flags cannot be modified (one of the bigger problems that need to be solved at some time IMO). So I just copied the Pulse app from `/system/demos/` to `/boot/home/`, opened it with the FileType Tracker add-on, and ticked its "*Background app*" checkbox.
+
+Then I added this to my `~/config/settings/boot/UserBootscript`:
+
+    # Launch Pulse, adjust Look & Workspaces flags
+    $HOME/Pulse &
+    waitfor "w>Pulse"                               # wait for the Pulse window thread
+    hey Pulse set Look of Window 0 to 20            # remove window border
+    hey Pulse set Workspaces of Window 0 to -1      # put on all workspaces
+
+Here's the bottom right corner of my screen; Pulse to the left, ActivityMonitor to the right:
+
+![Pulse to the left, ActivityMonitor to the right](https://www.haiku-os.org/files/blog/humdinger/Pulse+ActivityMonitor.png)
+
+The nice thing with Pulse: I can still resize and position the window with {{< keyboard CTRL >}}+{{< keyboard ALT >}}+right/left click-drag.

content/blog/krish_iyer/2018-05-06_[gsoc_2018_sdhci_mmc_driver]_week_1_and_2.md

@@ -22,7 +22,7 @@ Create a directory where you are going to save the build image and related files
 	mkdir generated.x86_64; cd generated.x86_64
 For compiling
 
-	../configure --build-cross-tools x86_64 ../../buildtools
+	../configure --cross-tools-source ../../buildtools --build-cross-tools x86_64
 
 ## Building Image
 Before building the image you need to install some dependencies

content/blog/leorize/2020-08-31_gsoc_2020_final_report_improving_and_extending_services_kit.md

@@ -0,0 +1,59 @@
++++
+type = "blog"
+title = "GSoC 2020 Final Report: Improving and Extending Services Kit"
+author = "leorize"
+date = "2020-08-31 02:00:18-05:00"
+tags = ["gsoc", "gsoc2020"]
++++
+
+Hi all. This is my final report on my project aiming to improve Services Kit,
+the networking backend behind most native Haiku application, most notably
+WebPositive.
+
+# Progress made during GSoC
+
+You may find the patches here:
+- [Haiku's Gerrit](https://review.haiku-os.org/q/hashtag:gsoc2020+owner:leorize%252Boss%2540disroot.org)
+- [HaikuWebKit's Github](https://github.com/haiku/webkit/pull/35)
+
+Here's the summary of some of the outstanding changes:
+- `BMemoryRingIO` is introduced for high-speed cross-thread communication. This
+  is an implemenation of a circular buffer with `BDataIO` interface. The
+  intended use case for this is for a HTTP/2 implementation, where one thread
+  will be the multiplexer and request threads will make use of this to retrieve
+  from the multiplexer.
+- `BUrlRequest` will now output directly into a `BDataIO`. This simplifies the
+  API for users as they can now reuse `BDataIO` implementations within Haiku
+  like `BFile`, `BMallocIO`, etc. without having to implement a
+  `BUrlProtocolListener`.
+- Introducing `BUrlSession` as a context manager allowing request handlers to
+  access and store session data. What this will enable is the ability to
+  reuse previously opened connections, which should reduce latency when
+  requests are opened against previously connected hosts. This portion is still
+  a WIP.
+- A clean up and rearchitecture of HaikuWebKit (WebPositive's engine) networking
+  was done which should improve reliablity. The rearchitecture also come with
+  fixes for HTTP authentication and redirection, which should now function
+  as well as other browsers.
+
+I'll be honest, I'm not happy with (relatively) small the amount of work that I
+have done during this GSoC, and I'm sorry for have not followed up with my set
+goals.
+
+# What's next?
+
+I'll continue to refine the changes as needed and potentially work on
+some optimizations like connection reuse that will be made possible by the
+changes done, but with my withering interest on this project, I can't promise
+anything.
+
+# Program experience
+
+I've learned a lot working on this project, especially about how much I still
+don't know about thread-safety, and I got to experience first hand the need for
+the many modern C++ features that I've come to take for granted
+(Services Kit has to be written in C++98 for gcc2 support).
+
+Regarding the mentorship, I have to thank waddlesplash and PulkoMandy for being
+very patient with my slow work pace, and for the helpful advices as well as
+the quick turnaround for all of my questions.

content/blog/mmu_man/2008-08-03_helping_on_m68k.md

@@ -24,7 +24,7 @@ There are some other 68k platforms around, like <a href="https://en.wikipedia.or
 
 <h3>Making a build</h3>
 It's not much different from a regular x86 build, the only difference being the target architecture. To get the required tools, just follow the <a href="/documents/dev/building_haiku_on_ubuntu_linux_step_by_step">Linux guide</a>, then when comes the time of configuring, instead we'll do a
-<pre>./configure  --build-cross-tools-gcc4 m68k ../buildtools/</pre>
+<pre>./configure  --cross-tools-source ../buildtools/ --build-cross-tools m68k</pre>
 This should build the cross compiler and set everything up.
 Then just go forward with a
 <pre>jam -q haiku-image</pre>
@@ -75,4 +75,4 @@ Now you should be set. To start the emulator, let's try:
 
 After a lot of messages, it should present you the familiar boot menu, where you can select the partition to use, and continue booting.
 Then it will load the kernel.
-I'm still working on getting the kernel on shape, so it won't go far, but feel free to help out.
+I'm still working on getting the kernel on shape, so it won't go far, but feel free to help out.

content/blog/mmu_man/2016-07-11_story_arcs_and_arch_stories.md

@@ -105,7 +105,7 @@ Buildtools still compile, here's what I use:
 <pre>
 mkdir generated-m68k-gcc4
 cd generated-m68k-gcc4
-../configure --build-cross-tools m68k ../../buildtools --use-xattr --use-gcc-pipe --distro-compatibility official --enable-multiuser --include-gpl-addons --include-patented-code --include-3rdparty --bootstrap ../../../haikuporter/haikuporter/haikuporter ../../../haikuports.cross/haikuports.cross ../../../haikuports/haikuports
+../configure --cross-tools-source ../../buildtools --build-cross-tools m68k --use-xattr --use-gcc-pipe --distro-compatibility official --enable-multiuser --include-gpl-addons --include-patented-code --include-3rdparty --bootstrap ../../../haikuporter/haikuporter/haikuporter ../../../haikuports.cross/haikuports.cross ../../../haikuports/haikuports
 </pre>
 
 I also built GDB from the 7.8 stock sources although I'm not sure I'll use it:

content/blog/nielx/2010-04-11_haiku_has_no_future.md

@@ -8,7 +8,7 @@ tags = ["presentation", "begeistert"]
 
 It was a few months ago that on a lazy Sunday afternoon I found myself to be in Brussels at the FOSDEM conference, where François organized a very successful Alt-OS development room, filled with all sorts of presentations on the world of the alternative operating systems. As probably the only non-computer science person, I got a slot as well and I decided to give a presentation with this same title. Now just imagine, I was scheduled on the last day, nearing the end of the conference (around four or five in the afternoon) and knowing the visitor group, I did not expect much. As such, I decided to prepare a discussion session for the ten or so people to show up. Now about five minutes before I was scheduled to go, people started trickling in. And to my pleasant dismay – if ever such a thing is possible – I ended up having a full house. Now why would a large number of computer geeks or – more nicely put – Open Source fanatics be interested in what a silly humanities guy has to say? I started to think about that, and I realize that this is in fact a very central question to everybody that donates time or money to these projects: what will be its future? Or put in another way, how can we, as actors in the always changing, always new information technology sector determine a path? That is the problem I would like to give a stab at in the coming twenty minutes.
 
-<I>This contains the text and the slides of a presentation I gave on the 11th of April 2010, at BeGeistert 022 in Düsseldorf. Attached you can find the slides and a printer-friendly version of this text.</I>
+<I>This contains the text and the slides of a presentation I gave on the 11th of April 2010, at BeGeistert 022 in Düsseldorf. You can get <a href="/static/files/Presentation-Haiku_has_No_Future-BeGeistert_022.pdf">the slides</a> and a <a href="/static/files/Text-Haiku_has_No_Future-BeGeistert_022.pdf">printer-friendly</a> version of this text.</I>
 
 <!--more-->
 
@@ -51,4 +51,4 @@ Because this leads to the third lesson: we are allowed to be playful and have fu
 
 <h3>Bibliography</h3>
 Edelman, Lee (2004). <i>No Future: Queer Theory and the Death Drive.</i> Durham NC: Duke University Press.
-Fuller, Matthew (2003). “It looks like you’re writing a letter: Microsoft Word.” <i>Behind the Blip: Essays on the Culture of Software.</i> New York: Autonomedia. Pp. 137-165.
+Fuller, Matthew (2003). “It looks like you’re writing a letter: Microsoft Word.” <i>Behind the Blip: Essays on the Culture of Software.</i> New York: Autonomedia. Pp. 137-165.

content/blog/nielx/2020-09-06_rust_on_haiku_the_case_of_the_disappearing_deceased_threads.md

@@ -0,0 +1,203 @@
++++
+type = "blog"
+title = "Rust on Haiku: the Case of the Disappearing Deceased Threads"
+author = "nielx"
+date = "2020-09-06 07:21:48+01:00"
+tags = ["haiku", "software", "rust", "developer"]
++++
+
+Summer! The time to slow down, relax, go to strange places, and do the projects that are long overdue. This summer I had the joy of spending my time in a lovely house near Lyon in France. In many ways the summer was like others, meaning there was plenty of wine and a lot of relaxing activities. At the same time, the Covid situation did give me a lot of reasons to scale back exploratory activities at the tourist hot spots, and instead focus on activities close to home. I decided to seize the opportunity and to see if I could dive into one of my long-standing pet peeves in the Haiku ecosystem.
+
+For a long time I have been maintaining the build of the Rust compiler and development tools on Haiku. For this purpose, I maintain a separate tree with the Rust source, with some patches and specific build instructions. My ultimate end goal is to have Rust build on Haiku from the original source, without any specific patches or workarounds. Instead we are in the situation where we cannot build rust on Haiku itself (instead we need to cross-compile it), and we need a customization to be able to run the Rust compiler (`rustc`) and package manager (`cargo`) on Haiku. This summer my goal would be to find out the underlying issue, and fix it so that the patch will no longer be necessary in the future. Let's go!
+<!--more-->
+
+## The Issue: Disappearing Threads
+
+The issue first appeared when trying to use `rustc` and `cargo` from Rust 1.21.1 to compile packages.  One of the tests I always do to see whether a generated Rust works, is to compile `cargo` itself. And the 1.21.0 version of cargo just failed. In particular, it failed with the following error: 
+
+```
+thread 'main' panicked at 'failed to join thread: No such process (os error -2147454963)', library/std/src/sys/unix/thread.rs:193:13
+```
+
+Looking at the [source](https://github.com/rust-lang/rust/blob/c3364780d2cfddfe329f62a3ec138fd4f9a60e27/library/std/src/sys/unix/thread.rs#L193), it seems to fail because of an error when the Rust library calls the `pthread_join()` function in Haiku's libraries. The entire method for `std::sys::unix::thread::Thread::join()`is:
+
+```rust
+pub fn join(self) {
+    unsafe {
+        let ret = libc::pthread_join(self.id, ptr::null_mut());
+        mem::forget(self);
+        assert!(ret == 0, "failed to join thread: {}", io::Error::from_raw_os_error(ret));
+    }
+}
+```
+
+It seems like the issue is that `pthread_join()` fails. The error code corresponds to `B_BAD_THREAD_ID`. This leads to the question: why does it fail? I mean, we spawned (or: created) the threads, so why would they disappear?
+
+The initial impulse for determining what happened is to determine what has changed from the standard library code in Rust 1.20.0 to make it behave this way? Let's compare to the previous version of this function:
+
+```rust
+pub fn join(self) {
+    unsafe {
+        let ret = libc::pthread_join(self.id, ptr::null_mut());
+        mem::forget(self);
+        debug_assert_eq!(ret, 0);
+    }
+}
+```
+
+It is not that the previous version worked differently, but it is that the error was only checked if the library was built in debug mode. Apparently the developers were confident enough that their library implementation was sound, so that they put this check in their production code. And since the binaries of `cargo` and `rustc` that I distribute are built in production mode, this means that on Haiku this error suddenly surfaced! It is very likely that `pthread_join()` has always ended with errors, it is just the case that now this leads to an end in the execution of the program because of the unconditional `assert!`. 
+
+In other words, the issue seems to be an interplay between the thing you are trying to do with `cargo`, Cargo's use of Rust's standard library, and the system.
+
+## Intermezzo: Joining Threads
+
+The issue seems to be in how `cargo` and/or the Rust standard library are using the threading system. As a quick catchup: threads are a technique for applications to execute code separately or independently from other parts of the program. It is often used to split up CPU intensive work, to take advantage of multiple cores. Rust uses the standardized [Posix Threads API](https://en.wikipedia.org/wiki/POSIX_Threads) (known as _pthreads_) to create and manage threads. Haiku has its own threading API, but it does support (a subset of) _pthreads_. 
+
+When a developer spawns threads, they may or may not care about the outcome of the thread. Let's say we have a tool that processes a file on the file system, and compares it against something on the network, we may want to get the network file in a separate thread, so that we can continue processing the file while the (slower) network operation is underway. In that case, I would spawn a thread using `pthread_spawn()` (let's call it `network-thread`), continue with the processing of the file in the `main-thread`, and afterwards use the result to compare. That means that after I am done in the `main-thread` , I will use `pthread_join()` to join with the other thread. If the `network-thread` is already finished, the call will return and I know I can use the result. If the `network-thread` is still busy, the `main-thread` will be blocked on `pthread_join()` until it is finished. 
+
+An alternative scenario is where a developer spawns a thread, but then does not care about its outcome. In that scenario they would call `pthread_detach()`, which tells the OS that the program does not care about the outcome and that it should not put any effort into tracking ended threads.
+
+In the way the Rust standard library uses the threads, they are not detached in any way. This means that `pthread_join()` should work! In other words, the issue seems to be that the system is forgetting about certain threads that were created.
+
+## Reproducing the Problem in Cargo
+
+The first step to fixing the issue is to find a way to reproduce it, preferably _reliably_ and _consistently_. For me, _reliably_ means being able to reproduce the problem using a set of predefined steps. Reproducing it _consistently_ means finding a fixed list of steps that will trigger the issue. 
+
+The first step then, was to create a build of Rust and its tools without the workaround, so that the error could occur. I used this custom build to then reproduce the issue.
+
+On the face of it, the issue was not that easy to catch. For example, it did not happen on every rust crate that you were trying to build. Some crates, like `socket2` and `libgit2-sys` would just succeed. Building `cargo` itself would trigger the issue, but only if it would build from scratch. That means that if I build the crate, and it fails with the error, re-running `cargo` would succeed. It would only fail again after cleaning out build artifacts.
+
+In order to find out more about what exactly leads to the failure, I decided to rerun the command with the `RUST_BACKTRACE=full` environment variable, in order to use Rust's internal stack trace mechanism. That lead to the following result:
+
+![Backtrace from Rust](/files/blog/nielx/20200906-rust-backtrace.png)
+
+Unfortunately, it is not very useful and has been broken [for a while](https://github.com/nielx/rust/issues/2). Let's see if our friend Debugger can help us get a stack trace. 
+
+![Backtrace from Debugger](/files/blog/nielx/20200906-debugger-backtrace.png)
+
+This gives us a more useful stack trace. The issue seems to be in threads that were created (and then joined) by the [jobserver crate](https://crates.io/crates/jobserver). This crate implements a method pioneered by `make` to allow   a ["form of parallelism limiting across process boundaries"](https://docs.rs/jobserver/0.1.21/jobserver/). I added more debug output to the code, and I found that for each crate that cargo has to build, it spawns a helper thread. Then at the end of the build process, `cargo` would try to join all the helper threads, failing on the first helper thread that was joined.
+
+## Writing a Test Case
+
+Now that we sort of have the rough outline, it would be helpful to narrow down the issue and to try to write a manual test that consistently and reliably fails in the same way. The reason is that it is reasonably easy to reproduce the issue with `cargo`, but that application itself does a lot of complex operations that obfuscate the issue at hand and might even make you go down rabbit holes. 
+
+In the initial simplest version we just spawn one thread and join it in later. This should not fail (applications on Haiku spawn threads all the time so any issues with this should be apparent. The source:
+
+```rust
+use std::thread;
+
+fn main() {
+    println!("Hello, world!");
+    let builder = thread::Builder::new();
+    let handler = builder.spawn(|| {
+    	println!("Hello, threaded world!");
+    }).unwrap();
+    
+    handler.join().unwrap();
+}
+```
+
+Let's run this 10,000 times to see if it breaks.
+
+```bash
+for i in `seq 10000`; do pthread_test ; done
+```
+
+Even running it a multiple of 10,000 times does not break. So let's see what happens if we spawn multiple threads within the same team. 
+
+I created a second version and I made some changes:
+
+* I create 57 threads, to emulate the behavior of cargo building cargo.
+* I run the threads for a little while (500 miliseconds).
+* I wait for all the threads to finish, before joining them. While analyzing the cargo case, I found the issue only occurred with threads that already ended.
+
+```rust
+use std::thread;
+use std::time::Duration;
+
+const NUM_THREADS: usize = 57;
+
+fn main() {
+    println!("Generating {} threads!", NUM_THREADS);
+    let mut handlers: Vec<thread::JoinHandle<_>> = Vec::new();
+    for _ in 0..NUM_THREADS {
+		let builder = thread::Builder::new();
+		let handler = builder.spawn(|| {
+			let timeout = Duration::from_millis(500);
+			println!("Hello, threaded world! Timeout: {} ms", 500);
+			thread::sleep(timeout);
+    	}).unwrap();
+    	handlers.push(handler);
+    }
+
+	let timeout = Duration::from_secs(60);
+	thread::sleep(timeout);
+	println!("Waited for threads to finish");
+
+    for handler in handlers {
+    	handler.join();
+    }
+}
+```
+
+On a Rust build with the workaround, this worked fine, but the issue did occur in the custom unpatched Rust build!  That's good, it seems like we are on to something. 
+
+## Down in the kernel
+
+The final part of our summer trip takes us into the depths of the kernel. Threads are created and maintained by the kernel. The `pthread_create()` ([source](https://github.com/haiku/haiku/blob/603367cf7e5d55b5d065b368b6d5f83b88db903f/src/system/libroot/posix/pthread/pthread.cpp#L147)) and `pthread_join()`([source](https://github.com/haiku/haiku/blob/603367cf7e5d55b5d065b368b6d5f83b88db903f/src/system/libroot/posix/pthread/pthread.cpp#L199)) functions are deferring to the kernel to do the heavy work. Our issue is in the `pthread_join()` method, which eventually ends up in the kernel's `wait_for_thread_etc()`([source](https://github.com/haiku/haiku/blob/603367cf7e5d55b5d065b368b6d5f83b88db903f/src/system/kernel/thread.cpp#L2453)) function, which does two things:
+
+1. Check if the thread is currently running.
+2. Check if the thread is on a _dead thread list_ for the team that is calling `pthread_join()`. ([source](https://github.com/haiku/haiku/blob/603367cf7e5d55b5d065b368b6d5f83b88db903f/src/system/kernel/thread.cpp#L2493))
+
+If the thread cannot be found on either of those lists, then the error will be `B_BAD_THREAD_ID`. And that's the familiar error with which this all started. Now from debugging `cargo`,  I knew that the threads that we were joining were no longer alive, so it is worth investigating how threads end up on this _dead list_. There is actually a kernel function named `thread_exit()`([source](https://github.com/haiku/haiku/blob/e65c8deae2bc8c8c9cd9285794ef926177bb9e8c/src/system/kernel/thread.cpp#L1945)) that does the cleanup when a thread ends, including adding things to the _dead list_. 
+
+```c++
+if (threadDeathEntry != NULL
+	&& list_is_empty(&thread->exit.waiters)) {
+	threadDeathEntry->thread = thread->id;
+	threadDeathEntry->status = thread->exit.status;
+
+    // add entry -- remove an old one, if we hit the limit
+	list_add_item(&team->dead_threads, threadDeathEntry);
+	team->dead_threads_count++;
+	threadDeathEntry = NULL;
+
+	if (team->dead_threads_count > MAX_DEAD_THREADS) {
+		threadDeathEntry
+			= (thread_death_entry*)list_remove_head_item(
+				&team->dead_threads);
+		team->dead_threads_count--;
+	}
+}
+```
+
+[Source.](https://github.com/haiku/haiku/blob/e65c8deae2bc8c8c9cd9285794ef926177bb9e8c/src/system/kernel/thread.cpp#L2137)
+
+Now this is where things get interesting. My eye immediately was drawn to this `MAX_DEAD_THREADS`, because if the number of dead threads in a team would be higher than this number, a thread would be thrown out of the _dead list_ meaning that `pthread_join()` would no longer be able to find it! The constant itself could be found in the private header [`thread_types.h`](https://github.com/haiku/haiku/blob/13beda00d3b2f67f45d9427396b9785145d07fb6/headers/private/kernel/thread_types.h#L99):
+
+```c++
+#define MAX_DEAD_THREADS	32
+	// this is a soft limit for the number of thread death entries in a team
+```
+
+After seeing this line, a long and loud 'Gotcha!' could be heard over the countryside in the Rhône-et-Loire province. Changing the test to lower the number of threads to 32 no longer created an error, and after I tweaked the Haiku kernel to allow for a higher limit of dead threads, all the previously failing tests and compiling Cargo worked!
+
+## Finalizing the Solution
+
+The final step of my summer bug hunt was to get the actual solution in the Haiku repository. After a [short discussion](https://www.freelists.org/post/haiku-development/Kernel-questions-joining-threads-and-the-limited-death-list) on the mailing list, I proposed a [change](https://review.haiku-os.org/c/haiku/+/3178) which was accepted after some tweaks. The Haiku kernel now no longer has a limit on the number of dead threads. There is an implicit trade-off here: the previous version uses a soft limit to impact the potential misuse of a developer that creates a lot of threads, but that never cleans it up. After discussing the downside to this, we decided that there are plenty of other ways to break a user's system, and misusing or abusing the threading system is very low down the list of things that might break a system. 
+
+The fix has landed in [hrev54540](https://git.haiku-os.org/haiku/commit/?id=331889d067f9a4c6984a8e34e55e73915e711754), meaning that every Haiku build after that revision, the Rust standard library will no longer need the workaround. Having said that, the binaries I am building will probably keep the workaround until Haiku Beta 3 is released.
+
+And with that, the summer is over!
+
+## Things along the way
+
+Some final notes, as one might wonder why it took me two weeks to actually find and fix the issue. During work I ran into a few mishaps along the way, that I patched or sent in patches for:
+
+* With the Rust 1.47.0 development code, cross compiling rustc seemed to fail suddenly. I asked for [some help](https://internals.rust-lang.org/t/solved-cross-compiling-rustc-from-bootstrap-broken-in-current-master-1-47-0/12902?u=nielx), and it turns out that this is a change in the build system and tweaking the command line options fix the issue, but [discussion is ongoing](https://github.com/rust-lang/rust/issues/76333) on whether this actually is a bug/regression in the Rust build system.
+
+* Also in Rust 1.47.0, the developers decided to enable zlib for LLVM. This means that the Rust build should link to `libz.so`. There's a [patch merged](https://github.com/rust-lang/rust/pull/75655) that fixes this.
+
+* On one of the side roads I took when trying to figure out how to reproduce it, I ran into the issue that the [net2 crate](https://crates.io/crates/net2) is still broken. While the crate is deprecated, it is still relied on by a lot of crates. I created a new [pull request](https://github.com/deprecrated/net2-rs/pull/103) that will hopefully make it in a future maintenance release.
+
+* Also I noted that Debugger support for Rust is lacking. The main issues are that (1) it does not seem to be able to map the symbols to files, even if the binary has the debug support, (2) for templated functions that are instanced for a specific type, Debugger gets confused on where the source is located and (3) Debugger does not find the main function. I will submit patches for (1) soon.

content/blog/preetpalkaur/2020-08-31_gsoc2020_final_report.md

@@ -0,0 +1,69 @@
++++
+type = "blog"
+title = "GSoC2020 Final Report: Input Preferences"
+author = "PreetpalKaur"
+date = "2020-08-31 21:15:52+05:30"
+tags = ["haiku", "software", "gsoc2020"]
++++
+
+# GSoC 2020 Final Report
+
+This is the final report of the GSoC 2020 project
+* [Input Preferences](https://summerofcode.withgoogle.com/projects/#6244788782759936)
+
+The proposal is available here:
+* [Proposal Link](https://docs.google.com/document/d/1WgHs9ZGMMxCZhHhy3BXZPtkht-aNvKEPA5fGTEfC82E/edit?usp=sharing">https://docs.google.com/document/d/1WgHs9ZGMMxCZhHhy3BXZPtkht-aNvKEPA5fGTEfC82E/edit?usp=sharing)
+
+## Work Done:
+- [x] Added the icons for each connected device in the input preferences application.
+  * [Icons](https://drive.google.com/file/d/10-kJdE4G0rGWiPZi4rudt4Vy1sOb6vRS/view?usp=sharing)
+- [x] Removed the unwanted devices from the device list when they are not connected to the computer.
+- [x] Improved the look of 4th and 5th button of the mouse and added the 6th button of the mouse and its working.
+  * [Buttons](https://drive.google.com/file/d/1TrRCrFDnQIOiZD6ZJItqmVlSddlVSbIq/view?usp=sharing)
+- [x] Made the Joystick GUI.
+  * [Joystick GUI](https://drive.google.com/file/d/1h5nhvRd1EY78UhtdQIePJoe4FzoyZ7XD/view?usp=sharing)
+- [x] Made the Wacom tablet GUI.
+  * [Pen GUI](https://drive.google.com/file/d/1CObvCO1vE6IQmY_r-Uwp0AKe9TClzTPg/view?usp=sharing)
+  * [Mapping GUI](https://drive.google.com/file/d/1JIWRtd5ceK1Adyg2jWKBb8bM2RIgjdQw/view?usp=sharing)
+- [x] Implemented the input preferences to hold settings for each mouse separately.
+
+## Commits:
+https://review.haiku-os.org/q/owner:preetpalok123%2540gmail.com
+
+## Weekly Blogs:
+http://preetpalk.wordpress.com/
+
+
+## Work TO DO:
+
+- [ ] Implement the settings of Joystick.
+- [ ] Implement the working of a Wacom tablet.
+- [ ] Implement the settings of each mouse from the back end.
+
+## Struggles:
+
+During the implementation of icons in the device list, I got the example from the media application and added the icons.
+
+To add the 6th button of the mouse, I got the example from the other mouse buttons.
+
+Implementation of mouse settings separately takes the time and it's still in process. There is no example where I can get an idea. It is the research work for me.
+
+I used the mapping concept to store the settings for each mouse with its name and is working fine on the GUI basis. Back end implementation is time-consuming. I am one step behind to the solution because I am unable to get the names of the mice in the input server. If I get the names some how it's in the binary format!
+
+While trying to solve this issue, if there is something happens wrong in the code the mouse and the keyboard stops working. To test the code each time I have to make the package and reboot the haiku. With that, the old packages also stops working due to the fault in the kernel.
+
+Each time I have to need to re-install the haiku from the CD. It's not enough while booting the haiku from CD, it shows the debugger window because of kernel fault and unable to install it.
+
+For the above issue, If I access the haiku from Linux, the Linux does not know how to write on haiku!
+
+The last option is to use qemu. I accessed the haiku partition from the haiku installed in the qemu and replaced the packages from /system/packages with /boot/system/packages. After doing this, the haiku runs successfully. I need to re-build it and installed the packages, again the time-consuming task.
+
+While trying to resolve the issue, I don't know whether the debugger window opens or not due to the changes added by me. Till now, I have to repeat the above steps about 5 times.
+
+At the time of the timeline, I did not expected these type of issues. :(
+
+I have learnt so many new things in these three months about haiku and git.
+
+I am also working with haiku after GSoC as a part of my 6 months of industrial training. And also try to complete my project. :)
+
+Thankyou :)

content/blog/pulkomandy/2020-11-16-haiku_activity_report_october_2020.md

@@ -0,0 +1,136 @@
++++
+type = "blog"
+title = "Haiku activity report - October 2020"
+author = "pulkomandy"
+date = "2020-11-16 10:14:07+02:00"
+tags = []
++++
+
+Welcome to the October activity report!
+
+I had managed to get other people to write the report for a few months, but
+not for October, apparently. So, I'm back!
+
+This report covers hrev54609-hrev54715 (about a month and a half work).
+
+The focus is not much on new and exciting features this month, there is a lot
+of bug fixing and cleanup work going on, as well as some performance improvements,
+and compatibility fixes for easier application porting.
+
+<h3>Code cleanup and other invisible changes</h3>
+
+Korli has added support for detecting several CPU features (instruction set
+extensions) which were added by Intel and AMD over the last few years.
+
+Kallisti5 reworked the options to the configure script which were a bit confusing
+since the introduction of hybrid builds (yes, that was about 10 years ago). Now
+the path to the buildtools repo and the architectures to build for are specified
+in two different options instead of being somehow merged into one.
+
+mt has run the code through the clang static analyzing tools and is fixing many
+small issues in the code, such as insecure printf format strings, dead assignments,
+and various other things. The code will be more safe and will have less warnings.
+
+Waddlesplash fixed the code to detect the gcc version to handle gcc 10 as a version
+newer than 2 (it was only looking at the first character of the version and thinking
+it was gcc1). He also fixed an issue in the stdbool.h implementation for gcc2, to
+make sure it can be built with modern compilers.
+
+Waddlesplash finished the work to relicense ProcessController under the MIT license.
+All people who had contributed to work on the tool agreed to relicense their work,
+except one. The remaining bit of GPL code (it was a trivial bugfix) has been
+removed then reimplemented independently under the new license.
+
+Leorize made the BUrlRequest constructor private, as it should have been.
+Requests should be created only by the BUrlProtocolRoster. Enforcing this
+will make it easier to migrate to his new services kit implementation, when
+it's ready.
+
+Kallisti5 fixed build of Haiku from a Linux install using gcc10.
+
+apl continue his work on HaikuDepot with various code cleanups and optimizations.
+
+Kyle Ambroff-Kao fixed Autoraise's icon loading.
+
+Mark Barnett fixed the makefile_engine to allow building drivers for 64bit haiku.
+
+Korli fixed a panic at boot on some CPUs where the XSAVE context length could
+not be detected. We now use a safe default value in that case.
+
+<h3>Documentation</h3>
+
+Humdinger fixed typos and did some rewording in the Haiku Interface Guidelines.
+
+Adam Fowler contributed some documentation for the accelerant interface.
+
+Nielx continues his work on filling in the haiku book, with documentation for
+BControl, hiding some private APIs that were not meant to be in the book (yet),
+and added doxygen files for generating the internal documentation (meant to be
+used as a reference by OS developers, but that would go too far into internal
+details for someone looking into just using the APIs to write an application).
+
+<h3>POSIX compatibility</h3>
+
+korli added the dprintf function, which allows to do formatted prints directly
+into a file opened with an unbuffered file descriptor (from open), similar to
+fprintf (which works with files opened with fopen instead).
+
+This had not been done before because the name of the function is conflicting with
+our kernel debug function (also named dprintf, but doing a different thing).
+The POSIX dprintf is not available in kernel mode, and various pieces of code
+that can be built both for userland and kernel have been adjusted.
+
+korli also added _SC_TTY_NAME_MAX to the supported sysconf parameters, added
+tcgetsid, fixed the definition of in6_addr, improved strace output for termios
+ioctls, and relaxed some checks in handling of network ioctls to fix
+incompatibilities with old OpenJDK versions. He also fixed handling of O_APPEND,
+added aligned_alloc (as specified in C11), made fsync() return EINVAL on fifos,
+and moved asprintf and vasprintf to BSD extensions as they are not part of POSIX.
+
+<h3>Graphics and app_server</h3>
+
+Korli added a way to create a BCursor from an arbitrary BBitmap, allowing for
+larger cursors (needed in Qt applications that use large custom cursors, for
+example). The existing APIs allowed only fixed size bitmaps of 16x16 pixels.
+
+John Scipione continues his work on the BeControlLook, making Haiku look
+pixel-for-pixel identical to BeOS for maximal compatibility.
+
+X512 fixed a drawing glitch in menus when their content is changed while they
+are open.
+
+<h3>Drivers</h3>
+
+Korli added support for more devices to the i2c and thermal drivers, allowing
+to access motherboard and CPU temperature information.
+
+PulkoMandy fixed a bug in the USB HID driver that would lead to USB mouses
+being listed as both a mouse and a keyboard in input preferences.
+
+Anarchos fixed the handling of the Pause key on PS/2 keyboards.
+
+X512 made several drivers properly report their names in the Devices preferences.
+The plan is to reliably report in Devices preferences if a particular device
+has a loaded driver or not.
+
+<h3>Filesystems and storage</h3>
+
+Parts of this summer GSoC work from cruxbox (on XFS) and Suhel Mehta (on UFS2)
+were merged. The filesystems are still not quite ready for day to day usage,
+however.
+
+PulkoMandy's work on MMC and SDHCI (for eMMC and SD cards) has been merged but
+is still incomplete and not enabled by default.
+
+Korli added posix_fallocate with the matching syscall to preallocate disk space
+before writing it, and also added an implementation for SEEK_DATA and SEEK_HOLE
+in lseek.
+
+kallisti5 changed the write() implementation to allow 0-byte writes, as needed
+by the Go port.
+
+<h3>Installer</h3>
+
+Installer can be used again to erase an existing install while preserving user
+data and settings. This can be used to restore an unbootable system while keeping
+the user data.

content/blog/suhelmehta/2020-08-26_gsoc_2020_project_update_ufs2_reading_files.md

@@ -0,0 +1,54 @@
++++
+type = "blog"
+title = "GSoC 2020 Project Update(UFS2): Reading Files"
+author = "SuhelMehta"
+date = "2020-08-26 16:40:58+00:00"
+tags = ["haiku", "software", "gsoc", "gsoc2020", "file system"]
++++
+
+Hello Everyone!
+
+This is my third post related to my project, *Adding UFS2 file system in Haiku*
+
+The link below provides the patches that I have worked on till now. 
+
+[Know more](https://review.haiku-os.org/q/owner:suhelmehta%2540outlook.com)
+
+## Work done till now
+The following points briefly describes what I have done till now:
+
+- Reading a file in a UFS2 formatted disk
+    - Implemented *ufs2_open()*, *ufs2_read()* in kernel_interface.cpp
+
+- Reading data from block pointers
+    - Modified *struct ufs2_inode* in Inode.h
+    - Implemented *GetBlockPointer()*, *GetIndirectBlockPointer()*, *GetDoubleIndirectBlockPtr()*, *GetTripleIndirectBlockPtr()* to get the block pointer from ufs2_inode
+
+- Get the block from file offset
+    - Implemented *FindBlock()* and *ReadAt()* in Inode.cpp
+
+- Modified DirectoryIterator::GetNext() to use ReadAt()
+
+---
+
+### Reading files
+
+UFS2 divides file system into blocks that are made up of fragments and size of block and fragments are written in super block(fs_bsize and fs_fsize in ufs2.h). Let us consider that the block size is 32 KB or 32768 Bytes and fragment size is 4 KB or 4096 Bytes. When ufs2_read() is called it is provided with a pos parameter (Or we can say the number of bytes already read in a file or file_offset). Now the content of the file is in direct blocks and each block is 32KB long. Now from file_offset we can calculate the number of direct block(file_offset / size_of_direct_block) at which content is present. If the number is greater than 11 then it means that content will move to a direct block but in order to reach that direct block we have to first reach the position of the indirect block that contains the pointer to the 12th direct block. Now the total number of direct block pointers in an indirect block can be  size_of_direct_block / 8 (let us say that 32768/8 is 4096, means 4096 direct block pointers in an indirect block, so file of size 128MB can be stored in indirect blocks). Hence the total file that can be stored in the first twelve direct blocks + indirect blocks is 128.384MB.
+
+Similarly the double indirect blocks contain, size_of_direct_block / 8, indirect block pointers.
+
+So, in order to reach the block we must multiply the fragment size with block pointer present in the inode.
+
+## Learning new things
+
+It is a great learning experience for me and I have learnt new things like
+
+- Storage of data on the disk
+- Datatypes of C++
+- Git commands
+
+## Resources
+
+[File system implementation](http://www.cs.cornell.edu/courses/cs4410/2016su/slides/lecture18.pdf)
+
+[UFS2 data blocks](https://cs.nyu.edu/courses/spring09/V22.0202-002/lectures/lecture-24.html)

content/blog/suhelmehta/2020-08-26_gsoc_2020_project_update_ufs2_reading_symboliclinks.md

@@ -0,0 +1,50 @@
++++
+type = "blog"
+title = "GSoC 2020 Project Update(UFS2): Reading Symboliclinks"
+author = "SuhelMehta"
+date = "2020-08-26 16:37:13+00:00"
+tags = ["haiku", "software", "gsoc", "gsoc2020", "file system"]
++++
+
+Hello Everyone!
+
+This is my another post related to my project, *Adding UFS2 file system in Haiku*
+
+The link below provides the patches that I have worked on till now.
+
+[Know more](https://review.haiku-os.org/q/owner:suhelmehta%2540outlook.com)
+
+## Work done till now
+The following points briefly describes what I have done till now:
+
+- Reading a symbolic link in a UFS2 formatted disk
+    - Implemented *ufs2_read_link()* in kernel_interface.cpp
+
+- Reading data from block pointers
+    - Modified *struct ufs2_inode* in Inode.h
+    - Modified *GetBlockPointer()*, *GetIndirectBlockPointer()*, *GetDoubleIndirectBlockPtr()*, *GetTripleIndirectBlockPtr()* to get the block pointer from ufs2_inode
+
+- Implemented *ReadLink()* in Inode.cpp
+
+---
+
+### Reading symbolic links
+
+UFS2 keeps the orignal file's path in the inode and it can be found in the 15 block pointers. In case of a symbolic link the characters or string is present at the block pointers but in case of file or directory there will be integer value.
+
+I have modified the ufs2_inode stucture in the following way
+
+```
+union data_blocks{
+
+    struct ptr_blocks {
+		int64_t directBlkPtr[12]; /* 12 direct block pointers */
+		int64_t	indirectBlkPtr;  /* 1 Indirect block pointer */
+		int64_t	doubleIndriectBlkPtr; /* 1 Double Indirect block pointer */
+		int64_t	tripleIndriectBlkPtr; /* 1 Triple Indirect block pointer */
+	}get_blocks;
+
+	char symlinkpath[120];
+
+}_blocks;
+```

content/community/getting-involved/_index.md

@@ -41,7 +41,6 @@ There are a lot of ideas of what could be improved or set up, like:
 * [openQA](http://open.qa) testing
 * Single sign-on ("Haiku account")
 * Reworking the user guide translator to use a modern framework
-* Make Haikuporter compatible with Python 3
 
 These are nice to have, but with the current time budget we can't afford additional maintenance burden.
 

content/community/getting-involved/developing/_index.html

@@ -10,11 +10,19 @@ tags = []
 <p>Check out the following areas that need help from new developers:</p>
 <HR>
 <h2>Core System</h2>
-<p>You can contribute code to Haiku by submitting a patch to the <a href="https://dev.haiku-os.org">Haiku development bug tracker</a> in a ticket. You should first read the <a href="/development/coding-guidelines">Haiku Coding Guidelines</a>, the guide on how to <a href="https://dev.haiku-os.org/wiki/CodingGuidelines/SubmittingPatches">submit patches</a> to the bug tracker and the bug tracker's <a href="https://dev.haiku-os.org/wiki/BugTrackerEtiquette">guide on etiquette</a>. There's a <a href="/development/getting-started">step by step guide</a> aimed at new contributors.</p>
-<p>You will need to learn how to <a href="/guides/building">build Haiku</a> from source and <a href="https://dev.haiku-os.org/wiki/GitStarted">learn how to use git</a>, the source code repository management system.</p>
+<p>You can contribute code to Haiku by submitting a patch to <a href="https://review.haiku-os.org">Haiku Gerrit</a>. You should first read the <a href="/development/coding-guidelines">Haiku Coding Guidelines</a> and the bug tracker and the bug tracker's <a href="https://dev.haiku-os.org/wiki/BugTrackerEtiquette">guide on etiquette</a>. There's a <a href="/development/getting-started">step by step guide</a> aimed at new contributors.</p>
+<p>After you get the Haiku <a href="https://www.haiku-os.org/guides/building/get-source-git/">source code</a> and learn how to submit patches, you will need to learn how to <a href="/guides/building">build Haiku</a> from source and <a href="https://dev.haiku-os.org/wiki/GitStarted">learn how to use git</a>, the source code repository management system.</p>
 <p>Developers that aim to eventually gain direct commit access to the Haiku repository, need to be subscribed to the <a href="https://www.freelists.org/list/haiku-commits">commit mailing list</a> to be able to participate in the code review process and join the <a href="https://www.freelists.org/list/haiku-development">development mailing list</a> for discussions.</p>
 <p>A <a href="/development/faq">development FAQ</a> is available to answer frequently asked questions and there is a <a href="/development/programming_with_haiku">study book available</a> to help you learn the Haiku API.</p>
 
+<h6>Highest Priority Items</h6>
+<ul>
+<li><a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FWebPositive&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority">WebPositive Improvements</a></li>
+<li><a href="https://dev.haiku-os.org/ticket/16217">Improve the Installer Experience</a></li>
+<li>Good Media Support (<a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EKits%2FMedia+Kit&col=id&col=summary&col=status&col=component&col=type&col=priority&col=milestone&order=priority">MediaKit</a>, <a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FMediaPlayer&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority">Media Player</a> Improvements)</li>
+<li><a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=reopened&status=new&group=status&milestone=R1">Bug fixes!</a></li>
+</ul>
+
 <h6>Core Development Opportunities:</h6>
 <ul>
 <li><a href="/community/getting-involved/developing/system#drivers">Drivers</a></li>

content/community/getting-involved/developing/applications.html

@@ -27,16 +27,28 @@ tags = []
 <li>…and of course you can extend this with more ideas for improvements.</li>
 </ul>
 
+<p>Current list of tickets can be found <a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FMail&col=id&col=summary&col=status&col=component&col=type&col=priority&col=milestone&order=priority">here</a>.</p>
+
 <h4>Updating and Extending WebPositive</h4>
-<p>Haiku uses a WebKit based browser called WebPositive. The browser is still quite simple and can be improved in multiple ways. Some of the missing features are:
+<p>Haiku uses a WebKit based browser called WebPositive. The browser is still quite simple and is in need of urgent bug fixes and improvements. It's missing important features, like:
 </p>
+
 <ul>
-<li>Missing session management. Opened tabs should be remembered and restored when the program is exited and restarted.</li>
-<li>Missing Cookie Jar management. There should be a way to list, delete and edit network cookies.</li>
-<li>Missing management of broken HTTPS certificates. There should be a way to remember exceptions to the system-wide certificate list.</li>
-<li>Support for browser extensions, such as ad-block. This could be done either reusing extensions from other browsers (if possible), or using the native add-ons system.</li>
+<li>Session management</li>
+<li>Proper cookie handling.</li>
+<li>Missing handling broken HTTPS certificates.</li>
+<li>Browser extensions.</li>
+<li>RSS reader</li>
+<li>Bookmark import/export</li>
+<li>Reader mode</li>
+<li>Dark mode support</li>
+<li>Search engine management</li>
+<li>Web fonts support</li>
+<li>And lots of bugs to squash!</li>
 </ul>
 
+<p>A full list of bugs and improvements can be found <a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FWebPositive&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority">here</a>.</p>
+
 <h4>DiskUsage</h4>
 <p>DiskUsage could be inproved by:</p>
 <ul>
@@ -50,7 +62,9 @@ tags = []
 Tickets: <a href="https://dev.haiku-os.org/ticket/5513">#5513</a> & <a href="https://dev.haiku-os.org/ticket/10282">#10282</a>
 
 <h4>People</h4>
-<p>The People application is our contacts manager that uses system metadata to store contact information. We need someone to modernise the application and allow it to import (or sync) contacts from online services such as Google Contacts. </p>
+<p>The People application is our contacts manager that uses system metadata to store contact information. We need someone to modernise the application and allow it to import (or sync) contacts from online services such as Google Contacts, and implement support for vCard contacts. It needs a modern Haiku-like UI as well.</p>
+
+<p>Current list of tickets can be found <a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FPeople&col=id&col=summary&col=status&col=component&col=type&col=priority&col=milestone&order=priority">here</a>.</p>
 
 <h4>LaunchBox</h4>
 <p>LaunchBox is the Haiku dock application. It needs to be <a href="https://dev.haiku-os.org/ticket/9480">updated</a> to properly display mounted disks, overlays and disk usage instead of generic folder icons.</p>
@@ -67,98 +81,42 @@ Tickets: <a href="https://dev.haiku-os.org/ticket/5513">#5513</a> & <a href="htt
 <h4>Haiku SDK: Debugger</h4>
 <p>Our graphical debugger is now used as default in Haiku, but there are still some areas that need improvement to match the features of graphical debuggers on other systems.</p>
 
-<h4>Haiku SDK: IDE</h4>
-<p>Although there are a few lightweight IDEs available for Haiku, we need a full featured IDE like Qt Creator, CLion or KDevelop. The development of a fully featured IDE called <a href="https://github.com/waddlesplash/Heidi">Heidi</a> has been started, but needs further work.</p>
-
 <h4>Haiku SDK: Graphical Profiler/Tracer</h4>
 <p>We need something like KCachegrind, AMD CodeAnalyst or Stackify for Haiku.</p>
 
 <h4>MediaPlayer</h4>
 
-<h4>HaikuDepot</h4>
+<p>Haiku has a general purpose media player, but it is currently a bit buggy, and does not work as expected. It has performance and UX issues. A full list of tickets can be found <a href=https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FMediaPlayer&col=id&col=summary&col=status&col=component&col=type&col=priority&col=milestone&order=priority">here</a>.</p>
+
+<h4>HaikuDepot - SoftwareUpdater</h4>
+
+<p>HaikuDepot is used for browsing and installing packages. However, at the moment it tries to both act like a software market and a package manager GUI, but does not excel at neither. It can also be quite sluggish at times.</p>
+
+<p>SoftwareUpdater is the Haiku utility for updating system and downloaded packages through HaikuDepot. It works well, but it lacking in features, like selective package upgrades and a more informative GUI.</p>
+
+<p>A full list of issues can be found <a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FSoftwareUpdater&component=%5EApplications%2FHaikuDepot&col=id&col=summary&col=status&col=component&col=type&col=priority&col=milestone&order=priority">here></a>.</p>
 
 <HR>
 <a id="3party" name="3party"></a>
 <h2>3rd Party</h2>
 
-<h4>Calendar application</h4>
-<p>Create a native calendar application or port an existing calendar application to Haiku. The app should support creating events and saving them to event files augmented with attributes similar to how People file work for contacts. Additional features of the calendar app might also include support for recurring events, integration with other calendaring software such as Google Calendar or Microsoft Outlook™, and vCalendar support ; CalDAV synchronization, import of iCal files, and more.</p>
-
-<p>You should review existing calendar applications on Haiku/BeOS and other operating system to find out the key features for such an application. Then, decide if one of the applications linked above may be used as a starting point, or if it is better to start from scratch. Aside writting the application itself, it may be useful to improve the BDate, BTime and BDateTime in Haiku to make it possible to do date math easily, work with different timezones, and format dates represented using these classes, as well as relative durations ("Today", "2 days ago", ...), in a localized way.</p>
-
-<p>Some applications to look at for inspiration/examples:</p>
-<ul>
-<li>http://www.pulkomandy.tk/~beosarchive/?file=archive/source/utils/Organizer.zip</li>
-<li>https://github.com/HaikuArchives/Eventual (for screenshots, see: http://sourceforge.net/projects/eventual/)</li>
-<li>https://depot.haiku-os.org/a_book/</li>
-</ul>
-
-<h4>Graphical version control system Frontend</h4>
-<p>Windows has TortoiseSVN and TortoiseGIT. Choose your preferred VCS, and do something similar for Haiku's Tracker.</p>
-Ideas:
-<ul>
-<li>Create a CVS version control system manager like Atlassian Sourcetree</li>
-<li>Create a TortoiseGIT clone for Haiku</li>
-<li>Update the MoleSVN app to match the features of TortoiseSVN.</li>
-<li>Create something for Mercurial</li>
-</ul>
-
-<h4>Graphical project manager tool</h4>
-<p>BeOS had CodeWarrior IDE built-in, which makes it easy to create a new project and get started on development. Haiku currently only provide make and jam in the default installation, which is far less easy to use for starting developpers. The makefile engine is somewhat simpler, but more limited. All of these tools are to be used in text mode, not so good for beginners. Create some graphical tool to easily get started on 3rd party development in a few clicks.</p>
+<h4><a href="https://github.com/HaikuArchives/Calendar">Improve the Calendar application</a></h4>
 
 <h4>Photo Album</h4>
-<p>Update the application <a href="https://depot.haiku-os.org/album/">Album</a>Album to match the features of Google Picasa.</p>
-
-<h4>Download Manager</h4>
-<p>While BeGet and VWGet are available for Haiku, we still need a full featured Download Manager for Haiku.</p>
-
-<h4>Softphone</h4>
-<p>Update the application Whisper to match the features of soft phones on other systems.</p>
+<p>Update the application <a href="https://depot.haiku-os.org/album/">Album</a> to match the features of other modern photo organizers.</p>
 
 <h4>UML Modeller</h4>
 
-<h4>Photo post-production</h4>
-
-<h4>Presentation Creator</h4>
-
 <h4>Screen Reader</h4>
 
-<h4>Video DVD Backup</h4>
-
-<h4>Video DVD Authoring</h4>
-
 <HR>
 <a id="ports" name="ports"></a>
 <h2>Porting software</h2>
 
-<h4>Improving Haiku's WebKit1 port</h4>
-<p>Haiku has a native WebKit port which uses the WebKit1 API. This port is not complete and there are several bugs and minor problems which needs to be fixed.</p>
-<ul>
-<li>There are rendering problems on many web pages. Most of these happen because of missing features both in the WebCore graphics implementation and in the Haiku app_server. This includes missing or incomplete support for dashed lines, shadows, perspective transforms, and probably some bugs in already implemented features. These should be implemented so websites look closer to how they were designed.</li>
-<li>Another missing feature is the ability to load fonts into app_server dynamically. Currently the Haiku API only allows using existing fonts installed in specific system directories. This should be extended so WebKit can make use of fonts it downloads from the web. Some websites use these as pictograms, and not having the correct font results in unuseable websites.</li>
-<li>Even when it looks correct, the rendering in WebKit is usually quite slow. Causes for this are present both in the WebKit code and in Haiku's app_server, which takes care of the drawing. Review the code to identify performance problems, and rework it to make the browser feel faster.</li>
-</ul>
-
 <h4>Migrating Haiku WebKit port to WebKit2</h4>
 <p>Haiku has a native WebKit port which uses the WebKit1 API. Since this port was made, the WebKit project migrated to WebKit2, which provides several new features and separates the work in several processes to limit the impact of crashes in one or the other.
 </p><p>
 The goal of this task is to get WebKit2 to run on Haiku. This involves implementing the required inter-process communication primitives in WTF (first reusing the UNIX socket support used on Linux ports, then migrating to BMessages if this is relevant/useful), and writing a WebKit2-style API for WebKit, which can be used in native Haiku  applications. Proof of concepts could be a minimal browser, an update to the existing WebPositive, or adding a web view to existing applications such as Mail or fRiSS.</p>
 
-<h4>VirtualBox port to Haiku</h4>
-<p>VirtualBox is a virtual machine allowing to run an operating system inside of another. Porting it to Haiku would allow Haiku user to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.</p>
-<p>Starting from <a href="http://article.gmane.org/gmane.comp.emulators.virtualbox.devel/3384">this preliminary work</a>, continue and complete the port. This includes writing a native GUI for VirtualBox, getting it to run, and more importantly, work on the virtualization driver which will allow virtualbox to run the emulated machine using the native CPU. This makes the emulated system run at close-to-native speed, whereas a software emulation would be unbearably slow.</p>
-
 <h4>KVM acceleration for Haiku's QEmu port</h4>
 <p>QEmu is a virtual machine allowing to run an operating system inside of another. While there already is an Haiku port, it currently does not support any acceleration system through native virtualization (KVM/KQemu). This makes it too slow for many uses. Fixing this would allow Haiku user to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.</p>
-
-<h4>NetSurf<h4>
-
-<h4>OpenJDK<h4>
-
-<h4>QT<h4>
-
-<h4>Gnash<h4>
-
-<h4>Blender<h4>
-
-<h4>LibreOffice</h4>

content/community/getting-involved/developing/system.html

@@ -132,7 +132,6 @@ Haiku code to load the kernel is located in src/boot/platform. You can see the
 Power management
 </h4>
 
-
 <p>Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.</p>
 <p>Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:</p>
 <ul>
@@ -152,8 +151,11 @@ File Systems: Write support for more filesystems
 
 <p>Haiku has great support for its own file system, but most others are only available read-only. It is way better for interoperability with other systems to be able to write to these disks from Haiku.</p>
 <p>The goal of this project is to complete the existing support for one of the following filesystems in Haiku, working from the existing code base:</p>
+
 <ol>
 <li>ReiserFS <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/reiserfs">existing sources</a>, <a href="http://web.archive.org/web/20070717210450/http://www.namesys.com/X0reiserfs.html">official specifications</a>, <a href="http://p-nand-q.com/download/rfstool/reiserfs_docs.html">extra documentation on the FS layout</a></li>
+<!--<li>UFS2 (as used in *BSD): <a href="https://review.haiku-os.org/q/owner:suhelmehta%2540outlook.com">Current implementation</a></li>
+    <li>XFS</a>: <a href="https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/xfs">Current implementation</a></li>--!>
 <li>BTRFS: <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/btrfs">existing code</a>, <a href="https://btrfs.wiki.kernel.org/index.php/Main_Page">homepage</a></li>
 </ol>
 
@@ -167,14 +169,11 @@ File Systems: general improvements and new filesystems.
 <ol>
 <li>ext4: extend the <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/ext2">existing ext2 driver</a> to support new ext3 and ext4 features</li>
 
-<li><a href="http://en.wikipedia.org/wiki/Unix_File_System">UFS2</a> (as used in *BSD): <a href="http://fxr.watson.org/fxr/source/ufs/">FreeBSD implementation</a>, <a href="http://sourceforge.net/p/ufs2tools/code/HEAD/tree/trunk/ufs2tools/">u2fstools for windows</a> (BSD licensed, source can be reused)</li>
 
 <li>HAMMER FS: <a href="http://www.dragonflybsd.org/hammer/">homepage</a>, <a href="http://fxr.watson.org/fxr/source/vfs/hammer/?v=DFBSD">sourcecode</a> (3-clause BSD, a port of the existing code is ok)</li>
 
 <li><a href="http://en.wikipedia.org/wiki/JFS_(file_system)">JFS</a>: existing code in Linux is under the GPL, a rewrite under the MIT license is preferred. The <a href="http://jfs.sourceforge.net/project/pub/jfslayout.pdf">filesystem design and disk structures</a> are well documented.</li>
 
-<li><a href="http://en.wikipedia.org/wiki/Xfs">XFS</a>: <a href="http://xfs.org/index.php/Main_Page">Development community</a>, <a href="http://oss.sgi.com/projects/xfs/index.html">homepage</a>  (existing code in Linux is under the GPL, a rewrite under the MIT license is preferred)</li>
-
 <li><a href="http://en.wikipedia.org/wiki/Zfs">ZFS</a>: <a href="http://www.open-zfs.org/wiki/Main_Page">main page</a>, <a href="https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/fs/zfs">existing code</a> (Existing code is under the CDDL, a rewrite is preferred)</li>
 <li><a href="http://en.wikipedia.org/wiki/Server_Message_Block">SMB</a>, Windows shares: <a href="http://fxr.watson.org/fxr/source/fs/smbfs/?v=FREEBSD10">smbfs from FreeBSD</a> (2-clause BSD, code can be ported to Haiku)</li>
 </ol>
@@ -187,15 +186,6 @@ IMAP FS: File system access to an IMAP account
 
 <p>In Haiku emails are stored as individual <a href="http://www.haiku-os.org/docs/userguide/en/workshop-email.html">file with extended attributes</a>. The <a href="http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol">IMAP</a> protocol exposes mails in a folder hierarchy and makes it possible to "browse" a remote mail box. Mounting an IMAP account as a local file system is therefore a natural fit. The file system should have full read and write support (deleting mails (files), creating folders, and moving mails between folders, etc.) with local caching for better performance. The design of <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/netfs">netfs</a> and <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/nfs4">nfs4</a> implementations for Haiku, as well as the simpler <a href="https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/googlefs">googlefs</a> can serve as a reference on how to implement a network file system.</p>
 
-<h4>
-x86-64: Support for 32 bit userland
-</h4>
-
-<p>
-Haiku is currently available in both 32 and 64 bit versions. However, the 64-bit version is currently unable to run 32-bit applications, forcing application developers to provide a 64-bit version of their applications. This is reducing the adoption of 64bit versions of Haiku for lack of available applications.</p>
-<p>The goal of this task is to add a compatibility mode to the 64-bit kernel so it is able to run 32-bit programs. The issues in doing that involve adjusting syscall parameters, and mainly converting pointers from the 32bit userland to the 64-bit addressing used on the kernel side. 32-bit applications compiled for Haiku "x86" architecture should be supported. Handling of gcc2-compiled legacy BeOS applications may also be considered as an extended goal, but not as much important.</p>
-
-
 <h4>
 ARM port / device tree support
 </h4>
@@ -312,9 +302,7 @@ Preflet GUI refactoring
 Several preference applications (aka preflets) could be redesigned. Furthermore, there might still be code that does not yet use our layout API. This work may include (but is not limited to):
 <ol>
 <li>combining Keymap and Keyboard</li>
-<li>combining Mouse and Touchpad</li>
-<li><a href="https://dev.haiku-os.org/ticket/6983">#6983</a>Printer</li>
-<li><a href="https://dev.haiku-os.org/ticket/6206">#6206</a>integrate scrollbar options into a new Appearance preflet</li>
+<li><a href="https://dev.haiku-os.org/ticket/6983">#6983</a> Printer</li>
 <li>Shortcuts</li>
 <li>Notifications</li>
 </ol>
@@ -363,4 +351,5 @@ The Media Kit could support default nodes per application (either unset (system
 Streaming support for Media Kit and applications
 </h4>
 
-<p>The media kit and related applications in Haiku relies a lot on the BMediaFile being seekable. This makes it difficult to use with non-seekable media sources such as internet streams or DVD media. Rework what's needed to get them working properly.</p>
+<p>The media kit and related applications in Haiku relies a lot on the BMediaFile being seekable. This makes it difficult to use with non-seekable media sources such as internet streams or DVD media. Rework what's needed to get them working properly.</p>
+

content/community/gsoc/2020/students.html

@@ -1,235 +1,15 @@
 +++
 type = "article"
 title = "Students"
-date = "2020-01-13T19:04:24.000Z"
-tags = []
+date = "2019-01-09T19:04:24.000Z"
+tags = ["gsoc"]
 +++
 
-<h3>Student Application Mini-FAQ</h3>
+<p>This year, all 4 of our GSoC students completed their projects!</p>
+
 <ul>
-<li><strong>Where do I apply?</strong>
-	<br />Start from the <a href="https://summerofcode.withgoogle.com/">Google Summer of Code site</a></li>
-<li><strong>What ideas can I apply for?</strong>
-	<br />Check out our <a href="/community/gsoc/2020/ideas">List of Google Summer of Code Ideas</a></li>
-<li><strong>What info do you need in the application?</strong>
-	<br />See the <a href="#template">Application Template</a> below for reference</li>
-<li><strong>What if I still have questions?</strong>
-	<br />Send a message to the <a href="http://www.freelists.org/list/haiku">Haiku Mailing List</a> or contact Haiku's <i>Google Summer of Code</i> administrator (<a href="https://discuss.haiku-os.org/users/pulkomandy">PulkoMandy</a>).</li>
-
-<li><strong>Are there any other requirements?</strong><br />
-
-<strong>Applying students are required to submit a code contribution</strong> to
-our <a href="https://review.haiku-os.org/">change review tool</a>. This could either be a
-<a href="https://dev.haiku-os.org/query?status=assigned&status=new&status=reopened&summary=~easy">task marked easy</a>,
-<a href="https://xref.landonf.org/source/search?q=TODO&defs=&refs=&path=&hist=&project=haiku">TODO commented in code</a>,
-<a href="/development/coding-guidelines">code style cleanup</a>, or any other
-unlisted task. Submitting code that relates to your project will indicate a
-higher level of understanding and ability. The number and difficulty of resolved
-issues will be taken into consideration when evaluating your application. It is
-suggested to <strong>set the topic to "gsoc2020" on submissions</strong>,
-as this facilitates finding them in the future.</li>
-
-<!-- TODO link to queries for past year submissions, to show it is not that hard -->
-
-<li><strong>Why do you want a code contribution before I'm accepted?</strong><br />
-
-This serves several purposes. It displays that you have the most basic skills
-that are required: building Haiku from source, running Haiku either natively or
-inside a VM, and using tools for online collaboration (bug tracker, mailing
-lists, IRC, etc.). More importantly, it provides our mentors with some insight
-into each individual student's motivation and abilities. It is an opportunity
-for you, the student to showcase yourself and to convince us that you are indeed
-the right person for the job.
-<br/>
-The code contribution is a very important part of your application.
-<strong>Students who did not submit one, or submit something insufficient, will
-not be accepted into the program.</strong>
-
-</li>
-<li><strong>Should I use Haiku R1/beta1 or a newer nightly image?</strong><br />
-As a developer, you will be working with the most recent code and test your changes
-on the development branches, so a nightly image is recommended. You can use
-either a 32bit or 64bit one, as you prefer.
-</li>
-</ul>
-
-<a id="impress" name="impress"></a>
-<h3>Making a Positive Impression</h3>
-<p>In open source work, communication is the key. You will be working remotely, and will need to communicate with your mentor, and other members of the Haiku community, over the Internet. Show us you're able to work this way and interact with other Haikuers in a productive and efficient way.</p>
-<ul>
-<li><a href="https://dev.haiku-os.org/wiki/SubmittingPatches">Submit a patch</a>:
-<ul>
-<li><strong>that relates to your project</strong></li>
-<li>is quality code that conforms to our <a href="/development/coding-guidelines">Coding Guidelines</a></li>
-<li>feel free to submit more than one patch!</li>
-</ul>
-<li>Have a positive impact on mailing lists, <a href="https://dev.haiku-os.org">bug tracker</a>, and other public spaces</li>
-<li>Do your homework ; Show that you have:
-<ul>
-<li>researched your project</li>
-<li>an understanding of what needs to be done</li>
-<li>a proper plan for accomplishing it, which includes quantifiable goals and timelines</li>
-</ul>
-</li>
-<li>Submit an alternate proposal, as this provides our mentors with flexibility for choosing the best students, rather than the best project ideas</li>
-</ul>
-
-<a id="advice" name="advice"></a>
-<h3>Words of Advice</h3>
-<p>
-Reading and following this advice will do wonders for ensuring
-that your <i>Google Summer of Code</i> experience will be something to be proud of.
-</p>
-
-<ol>
-<li><strong>Dedicate at least 30 hours per week</strong><br />
-  As <i>Google Summer of Code</i> is essentially a work-from-home internship,
-  you are expected to put in the necessary time. To note, the majority of
-  Haiku's students who spent less than 30 hours per week, failed.
-</li>
-
-<li><strong>Communicate every other day</strong><br />
-  The haiku-gsoc mailing list is to be used at all times by you.
-  Provide regular reports. Nothing formal, just one or two lines.
-  It is important for your mentors to have a clear picture of what you are doing, have done, and plan to do.
-  While being self-sufficient is a worthwhile trait, it is not an ideal trait for a Google Summer of Code participant -- Haiku expects you to utilize our mentors, that is why they are there.
-</li>
-
-<li><strong>Provide code frequently</strong><br />
-  There is a saying in open source -- commit often, commit frequently.
-  Take that advice to heart.
-  Smaller patches and code snippets are easier for the mentors to review.
-  It also gives them more chances to suggest better approaches and keep you on target.
-  In turn, this will make you more productive and more likely to succeed!
-  You can put your work in progress changes in our code review tool so your mentor and other developers can help you spot the problems. It is perfectly fine to share non-working code, in fact a lot of the changes listed in the code review tool are in this case and several iterations will be needed to get things right.
-</li>
-
-<li>
-<strong>When you do not have code, it is even more critical to converse frequently.</strong><br />
-  If you aren't coding, what are you doing?
-  How are you moving closer to your goal?
-  What problems are you analyzing?
-  What questions and ideas do you have?
-  Every year, many students get stuck on an issue and spend too much time trying to solve it by themselve, when a mentor could help them progress much faster. This isn't a school assignment, we will not fail you for asking too much questions.
-</li>
-
-</ol>
-
-<a id="passorfail" name="passorfail"></a>
-<h3>Pass or Fail Criteria</h3>
-
-<p>As you know, <i>Google Summer of Code</i> has three monthly evaluation points.
-If you happen to receive
-a failing mark at either point, you are not paid that portion and your
-internship comes to an abrupt end. There are two areas
-that are considered during the evaluation: the code output and
-communication/interactions.
-</p>
-
-<p>
-  A word of caution -- do not expect to make miracles during the week
-  of mid-term or final evaluations. Instead, expect your mentor to
-  evaluate your progress on the first day of the window.
-</p>
-
-<ol>
-<li><strong>Code.</strong><br />
-  This includes everything from 'commit worthy' patches to all the code
-  (and non-code, such as design documents or pseudo code) leading up to
-  that polished patch. In other words, if for some reason you and your
-  mentor pursue an approach that turns out to be a dead end you will not
-  be punished.
-</li>
-
-<li><strong>Communication.</strong><br />
-  This includes discussions on the haiku-development list,
-  talking with haiku developers on IRC,
-  posting the Milestone Blog/Email Reports.</li>
-</ol>
-
-<p>
-  In other words, <strong>you will be writing code and talking with
-  one or more mentors on a daily basis.</strong> Anything less will
-  hurt your mid-term and final evaluation! Do not expect to be able
-  to cram days, weeks, or months of work into a shorter period and
-  receive a passing evaluation.
-</p>
-
-<a id="template" name="template"></a>
-<h3>
-Application Template
-</h3>
-<p>This application template has two sections.</p>
-<ol>
-<li>A fill-in-the-blank section with basic information.</li>
-<li>An open-ended section with suggestions for content to include. Feel free to add more.</li>
-</ol>
-<hr>
-<h4>(Fill in)</h4>
-<ul>
-<li>Full name:</li>
-<li>Timezone:</li>
-<li>Email address:</li>
-<li>IRC username (freenode.net):</li>
-<li>Trac username (dev.haiku-os.org):</li>
-<li>Gerrit changes submitted (review.haiku-os.org):</li>
-<li>(optional) GitHub (or other public) repository:</li>
-<li>(optional) emergency contact (please include contact information for someone we can get in touch with if something makes you unable to continue your project and you can't give any news to us):</li>
-
-<li>Will you treat <i>Google Summer of Code</i> as full time employment?</li>
-<li>How many hours per week will you work?</li>
-<li>List all obligations (and their dates) that may take time away from GSoC (a second job, vacations, classes, ...): </li>
-<li>Are you using <i>Google Summer of Code</i> to fullfill a university requirement -- internship, class credit, ..? (If yes, you need to provide confirmation that your school approves. Remember, <i>Google Summer of Code</i> is a remote software development internship.)</li>
-<li>How and when did you first heard about Haiku?</li>
-<li>Did you also apply to other GSoC organizations? If so, which is your order of preference? (this has no impact on the selection process, we use this information only if you are selected as an intern by several of these organizations to decide which one would keep you)</li>
-<li>Estimated last day of classes/exams:</li>
-<li>Estimated first day of classes (for most interns, there will be some overlap with the GSoC coding period. This is fine, but we want to check that you have planned your timeline accordingly):</li>
-</ul>
-
-<h4>(Open-ended)</h4>
-<ol>
-<li>Introduce yourself. (Who you are. Why you chose Haiku. What programming experience you have.)</li>
-<li> Project Proposal. (Title. Description. Goals.)</li>
-<li> Timeline. Include what you plan to have accomplished by the end of:
-<ul>
-  <li>Community bonding period (May)</li>
-  <li>First month of coding (June)</li>
-  <li>Second month of coding (July)</li>
-  <li>Third month of coding (August)</li>
-  <li>After Google Summer of Code</li>
-</ul></li>
-<li>Expectations from Mentors. (What do you expect Haiku's mentors to help you with?)</li>
-</ol>
-
-<hr>
-
-<p>If you have questions about your application for a Haiku idea, please contact Haiku's <i>Google Summer of Code</i> administrator (<a href="https://discuss.haiku-os.org/users/pulkomandy">Adrien Destugues</a>), or send an email to the <a href="http://www.freelists.org/list/haiku">Haiku mailing list</a>.</p>
-
-<h3>Resources available to students</h3>
-<p>
-In addition to the mentor(s) assigned to each student, the following resources will be available where inquiries can be made in order to get assistance during your <i>Google Summer of Code</i> project.
-</p>
-<ul>
-<li class="icon-folder-mail"><strong>Mailing list:</strong> <a href="http://www.freelists.org/list/haiku">Subscribe here</a></li>
-<li class="icon-folder-people"><strong>IRC channel:</strong> <a href="irc://chat.freenode.net/%23haiku">#haiku@chat.freenode.net</a> (<a href="http://webchat.freenode.net/?channels=haiku">browser-based client</a>)</li>
-<li class="icon-folder"><strong>Haiku Guides:</strong>
-	<ol>
-	<li><a href="https://cgit.haiku-os.org/haiku/plain/ReadMe.md">An introduction to the Haiku project</a></li>
-	<li><a href="https://cgit.haiku-os.org/haiku/plain/ReadMe.Compiling.md">Building Haiku from source</a> (single plain text file)</li>
-	<li><a href="/guides/building">Building Haiku from source</a> (html)</li>
-	<li><a href="/guides/installing">Installing Haiku</a></li>
-	<li><a href="/documents/dev/a_brief_introduction_to_our_source_repository_layout">A Brief Introduction to our Source Repository Layout</a></li>
-	<li><a href="/development/coding-guidelines">Coding Guidelines</a></li>
-	<li><a href="https://dev.haiku-os.org/wiki/SubmittingPatches">Submitting a patch to Haiku</a></li>
-
-</ol></li>
-
-</ul>
-
-<h3>For more information</h3>
-
-<p>For more information about general information and eligibility for <i>Google Summer of Code</i> 2020, please check out the following Google resources:</p>
-<ul>
-<li class="icon-html"><a href="https://developers.google.com/open-source/gsoc/resources/">Google Summer of Code Resources</a></li>
-<li class="icon-html"><a href="http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/">GSoC Student Guide: What is Google Summer of Code?</a>.</li>
+	<li><a href="/blog/cruxbox/">Cruxbox</a> - XFS filesystem support</li>
+	<li><a href="https://preetpalk.wordpress.com/">Preetpal Kaur</a> - Input preferences</li>
+	<li><a href="/blog/leorize">Leorize</a> - Services kit rewrite</li>
+	<li><a href="/blog/leorize">Suhel Mehta</a> - UFS2 filesystem support</li>
 </ul>

content/community/gsoc/2021/ideas.html

@@ -0,0 +1,904 @@
++++
+type = "article"
+title = "Ideas"
+date = "2020-08-06"
+tags = []
++++
+
+<p>For information about Haiku's participation in GSoC this year, please see <a href="/community/gsoc/2021">this page</a>.</p>
+<p>
+Qualifying students can apply for a Haiku project (see the list of <i>suggested</i> projects below).
+For details about how to apply, please check out <a href="/community/gsoc/2020/students">Students: How to Apply for a Haiku Idea</a>.</p>
+
+<div class="alert alert-info">
+<p>The most successful <i>Google Summer of Code</i> projects are often those proposed by the students themselves.
+The following list represents some of our ideas and wishes for the project. However, suggesting your own idea is always encouraged!</p>
+</div>
+
+<p>Be aware: API design and kernel-related work requires a higher level of skill, and
+user interface design usually involves a lot more thought than other work. A
+significantly more convincing proposal is required for tasks involving those.
+Getting started with the design early (before the application period ends) is
+recommended, to maximize your chances of being selected, and allow a larger part
+of the coding period dedicated to coding tasks.</p>
+
+<p>If you find one of the "big" ideas interesting, but feel that you cannot
+complete it within the allotted coding time, feel free to suggest splitting it
+into smaller parts for your proposal.</p>
+
+<p>Students that intend to submit applications on ideas which are also part of
+other accepted mentoring organizations must coordinate with both Haiku and the
+other mentoring organization beforehand.</p>
+
+<h3>Project Areas</h3>
+
+<ul>
+<li><a href="#applications">Applications</a></li>
+<li><a href="#drivers">Drivers</a></li>
+<li><a href="#kernel">Kernel/File Systems</a></li>
+<li><a href="#media">Media</a></li>
+<li><a href="#network">Network</a></li>
+<li><a href="#user-interface">User Interface</a></li>
+<li><a href="#ports">Porting</a></li>
+<li><a href="#other">Other</a></li>
+</ul>
+
+<a id="applications" name="applications"></a>
+<h3>Applications</h3>
+
+<!-- on hold until webkit2 is ready, there's little point otherwise
+<h4><img src="/images/App_Generic_32.png"/>Updating and Extending WebPositive</h4>
+<p>
+Haiku uses a WebKit based browser called WebPositive. The browser is still quite
+simple and can be improved in multiple ways. Some of the missing features are:
+</p>
+<ul>
+<li>Advanced session management. There is minimal support for restoring tabs
+from the last closed window, but a more complete solution is desirable. The web
+browser should be able to store its whole state (multiple windows and tabs) to
+a session file, and restore the state from that file.</li>
+<li>Management of broken HTTPS certificates. There should be a way to remember
+exceptions to the system-wide certificate list.</li>
+<li>Support for browser extensions, such as ad-block. This could be done either
+reusing extensions from other browsers (if possible), or using the native
+add-ons system.</li>
+<li>Skill set: userland development, user interface design and programming</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy</li>
+<li><a href="https://git.haiku-os.org/haiku/tree/src/apps/webpositive">Source code</a></li>
+<li><a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FWebPositive">Opened tickets</a></li>
+</ul>
+-->
+
+
+<h4><img src="/images/App_Generic_32.png"/>Improving Haiku's WebKit2 port</h4>
+
+<h5>Idea description</h5>
+
+<p>Haiku has a native WebKit port which uses the WebKit1 API. This port is not complete and there are several bugs and minor problems which needs to be fixed.
+The plan is to replace this with a more up to date port based on the WebKit2 API. Based on the work completed in GSoC 2019, WebKit2 on Haiku is now able to render some web pages.
+The goal of this project is to continue this work, making the WebKit2 port more reliable, render all pages, handle input events, etc, and make it usable for the WebPositive browser.</p>
+
+<h5>Why we need this</h5>
+
+<p>The web browser is an important part of the operating system today. It is difficult to attract and retain sers if we don't provide a good web browser.
+When we started our efforts with WebKit, WebKit2 wasn't ready for our use yet, but today it is more mature and it is time to migrate to it.</p>
+
+<h5>Further reading</h5>
+
+<ul>
+<li>Skill set: userland development, exploring a large code-base (WebCore)</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy</li>
+<li><a href="https://github.com/haiku/webkit">Sourcecode (see the webkit2 branch)</a></li>
+<li><a href="https://www.haiku-os.org/blog/rajagopalan">GSoC 2019 blog</a></li>
+<li><a href="https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&component=%5EApplications%2FWebPositive">Opened tickets</a></li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>Better XMPP instant messaging client for Haiku</h4>
+
+<h5>Idea description</h5>
+
+<p>XMPP is a modern communication protocol for instant messaging. It has open standards and several free software client and server implementations.</p>
+<p>Currently, the available native clients for Haiku are quite simple and don't even allow to replace all IRC features. The goal of this project is
+to improve <a href="https://github.com/haikuarchives/renga">Renga</a>, one of such clients, to make it possible to migrate Haiku discussion channels over to XMPP instead of IRC.</p>
+<p>The main features to implement are more complete support for multi-user chat (in particular, moderation aspects, allowing to manage channel permissions, kick and ban users, etc)
+as well as any other feature considered useful: user avatars, pictures and file sharing, whiteboard collaboration, …</p>
+
+<h5>Why we need this</h5>
+
+<p>Most of Haiku communication channels are currently hosted on IRC servers. IRC is a
+simple protocol, but it lacks modern features and is difficult to use from unstable connections or using mobile phones.
+As a result, IRC is less popular, and a part of the Haiku community doesn't use it anymore.</p>
+<p>Since we prefer to support open source software and usage of Haiku, XMPP is a good candidate, if we can have a working native client allowing to use it.
+We don't want people to instead use closed-source software or undocumented protocols.</p>
+
+<h5>Further reading</h5>
+
+<ul>
+	<li>Skill set: userland development, user interface design</li>
+	<li>Possible mentors/knowledgeable people: PulkoMandy, waddlesplash</li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>VirtualBox port to Haiku</h4>
+
+<p>VirtualBox is a virtual machine allowing to run an operating system inside of another. Porting it to Haiku would allow Haiku user to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.</p>
+
+<p>Starting from <a href="http://article.gmane.org/gmane.comp.emulators.virtualbox.devel/3384">this preliminary work</a>, continue and complete the port. This includes writing a native GUI for VirtualBox, getting it to run, and more importantly, work on the virtualization driver which will allow virtualbox to run the emulated machine using the native CPU. This makes the emulated system run at close-to-native speed, whereas a software emulation would be unbearably slow.</p>
+
+<ul><li>Skill set: userland development, kernel development, possibly x86 assembly</li>
+<li>Possible mentors/knowledgeable people: mmu_man</li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>Hardware acceleration for Haiku's QEMU port</h4>
+
+<p>QEMU is a virtual machine which allows running an operating system inside of another. While there already is a Haiku port, it currently does not support any acceleration system through native virtualization (through Intel VT-x and AMD SVM.) This makes it too slow for many uses. Fixing this would allow Haiku users to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.</p>
+
+<p>Various systems exist on other operating systems for this, such as <a href="https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine">KVM</a> on Linux, <a href="https://wiki.freebsd.org/bhyve">bhyve</a> on FreeBSD and recently (in 2019) <a href="https://blog.netbsd.org/tnf/entry/from_zero_to_nvmm">NVMM</a> was added to NetBSD. Intel also has a cross-platform framework called <a href="https://github.com/intel/haxm">HAXM</a> which only works on their CPUs. All of these work with QEMU, while only some work with other virtual machine technologies like VirtualBox. Of all these NVMM seems to be the easiest to port to Haiku. Bhyve might also be viable, and has been ported to MacOS and Illumos (a Solaris derivative.) A student interested in this project should research NVMM, bhyve and some of the other virtualization systems and describe how they would approach a port to Haiku. Many times these systems make use of kernel technologies that Haiku lacks and so much of this project might involve adding those to Haiku's kernel.</p>
+
+<ul>
+<li>Work on a virtualization driver which will allow QEMU to run the emulated machine using the native CPU.</li>
+<li>Skill set: kernel development, userland development, possibly x86 assembly</li>
+<li>Possible mentors/knowledgeable people: mmu_man, waddlesplash</li>
+<li><a href="https://github.com/mmlr/qemu-haiku">Sourcecode (QEMU for Haiku)</a></li>
+<li><a href="https://nxr.netbsd.org/xref/src/sys/dev/nvmm/">NVMM Sourcecode</a></li>
+</ul>
+
+<h4><img src="/images/Prefs_Devices.png"/>
+Devices preferences/Hardware manager
+</h4>
+<p>Haiku is meant to be an easy to use graphical operating system. It should
+provide a GUI to manage devices and drivers. This is currently implemented in
+the "Devices" preferences, however it does little more than listing devices
+found on the machine.</p>
+<p>The goal of this project is to extend the functionality of Devices preferences
+to make it a more complete and useful tool. This includes working on the following features:
+<ul>
+<li>Telling wether a driver is loaded for a given device and where the matching /dev entry is</li>
+<li>Giving user readable information on the device type and subtype</li>
+<li>Allowing to blacklist/disable the driver for a given device</li>
+<li>Support for USB and bluetooth devices (currently not listed at all)</li>
+<li>Generation of a "compatibility report" to help populate an hardware compatibility database for Haiku</li>
+</ul>
+</p>
+<p>Note that a lot of the work may be in making the required information available
+from the drivers and existing device management infrastructure, and not just in
+building the GUI itself.</p>
+
+<ul>
+	<li>Skill set: user interface, kernel and drivers interfacing (ioctl, devfs...)</li>
+	<li>Possible mentors: PulkoMandy, waddlesplash</li>
+	<li>Existing code: <a href="https://cgit.haiku-os.org/haiku/tree/src/apps/devices">"Devices"</a></li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>Other applications</h4>
+<p>There are many open source 3rd party applications for Haiku that could use improvements. Whether it is resolving bugs, adding features, updating the coding style, updating them to use the Locale and Layout Kits, or anything else imaginable! Writing applications from scratch is also possible.</p>
+
+<ul>
+<li><a href="https://github.com/Barrett17/Caya">Caya</a> (IM client)</li>
+<li><a href="https://github.com/HaikuArchives/Torrentor">Torrentor!</a></li>
+<li><a href="https://github.com/HaikuArchives/Calendar">Calendar</a></li>
+<li><a href="https://github.com/HaikuArchives">Many applications at HaikuArchives</a></li>
+<li><a href="http://pulkomandy.tk/~beosarchive/">Lots of abandonned projects for BeOS looking for a maintainer</a></li>
+</ul>
+<ul><li>
+Skill set: userland development, user interface design, exploring an existing code base, others depending on the application retained.
+</li>
+<li>Possible mentors/knowledgeable people (depends on chosen application): PulkoMandy, Sean Healy, waddlesplash</li>
+</ul>
+
+
+<a id="drivers" name="drivers"></a>
+<h3>Drivers</h3>
+
+<h4><img src="/images/Prefs_Devices.png"/>
+	Improving intel video driver
+</h4>
+
+<p>Haiku comes with a video driver for intel chipsets. However, on many supposedly supported devices, the driver will
+only produce a black screen with no output, confusing users and forcing them to fallback to VESA video modes.
+</p>
+<p>The goal of this project is to improve the driver and fix the different problems, making sure we get video output
+working on all supported devices. This includes support for HDMI, DisplayPort and VGA outputs.</p>
+<p>Intel provides documentation for each generation of device, a lot of the work is figuring out what the differences
+between generations are, and which part the driver is currently not properly implementing.</p>
+
+<ul><li>Skill set: drivers development</li>
+	<li>Possible mentors/knowledgeable people: PulkoMandy, waddlesplash</li>
+</ul>
+
+<h4><img src="/images/Prefs_Devices.png"/>
+USB Support for FreeBSD network compatibility layer
+</h4>
+
+<p>Haiku uses a FreeBSD network compatibility layer to support many network devices (ethernet and wireless) using drivers written for the FreeBSD project. This allows reusing network drivers with very little changes, considerably decreasing the effort needed to get good hardware support in Haiku.</p>
+<p>However, this layer only supports PCI devices, and doesn't work with USB ones. Adding support for USB to the compatibility layer would bring us support for a range of devices like so-called USB tethering, as well as USB to Ethernet and WiFi dongles.</p>
+
+<p>This project consists in importing one or more USB network drivers from FreeBSD into Haiku sources. The compatibility layer should then be extended to expose the FreeBSD USB APIs to the drivers, and forwarding the calls to Haiku's USB stack. Other parts of the compatibility layers may need to be extended as well.
+</p>
+<p>This should be tested either with real hardware or an emulated device in a virtual machine.</p>
+
+<ul>
+<li>Skill set: kernel and driver development, USB, general C and C++ development</li>
+<li>Possible mentors: waddlesplash, korli</li>
+</ul>
+
+
+<!-- USB isochronous appears to work well enough, to be revisited with more focus
+	on the webcam and audio drivers
+<h4><img src="/images/webcam.png"/>
+Isochronous USB transfers (USB Webcam &amp; soundcard support)
+</h4>
+<p>Currently Haiku has very limited support for webcams and USB sound cards.
+The goal of this task is to improve the WebCam or USB audio drivers, in order
+to make them production ready. For both of these, the USB specification has a
+well-documented standardized way to communicate with the devices. Haiku has a
+working driver for sound cards, and an incomplete one for webcams.</p>
+
+<p>The main area of work for this project would be getting isochronous USB
+transfers to work in Haiku. The USB specification defines various types of
+transfers on the USB bus, which affects the scheduling and how the data is
+exchanged between the computer and USB devices. The isochronous mode is used
+for low latency applications where a reliable and predictible timing is
+required (as is the case for video and audio streams).</p>
+
+<p>Unfortunately, Haiku implements these transfers completely only for some
+USB1 controllers. There is partial support, but it is not fully working.</p>
+
+<p>The first part of this task is to investigate the state of isochronous
+transfers and what is missing to get them working. Then, of course, actually
+making things work. Once this part is sorted out, the audio and webcam drivers
+may also need some work to get everything running smoothly.</p>
+
+<ul>
+	<li>Requirements: USB audio or webcam device (a laptop with built-in webcam should do)</li>
+	<li>Skill set: kernel and driver development, USB, C and C++ development</li>
+	<li>Possible mentors: PulkoMandy</li>
+</ul>
+-->
+
+
+<!-- Mentors wanted
+<h4><img src="/images/App_Generic_32.png"/>
+ACPI Video Extensions
+</h4>
+
+<p>ACPI Video Extensions, as specified in ACPI Spec 4.0a Appendix B, adds special support to handle multiple output devices such as panels and TV-out capabilities, brightness control as well as special power management features.</p>
+
+<p>Suggested work: Detect attached devices for display adapters, implement a basic driver for a display, allow display switching and brightness control.</p>
+<ul>
+<li>Requirements: computer with ACPI that has ACPI Video Extensions (_DOS _DOD and so on)</li>
+<li>Skill set: kernel development, general C/C++, userland development</li>
+</ul>
+
+
+-->
+
+
+<!-- REMOVED; need investigation, possibly easier to use DragonFlyBSD's compatibility layer to get all drivers from Linux
+<h4><img src="/images/App_Generic_32.png"/>Nouveau / PSCNV port</h4>
+<p>
+Haiku currently doesn't have a driver for NVidia video cards, and falls back to VESA for those. While our VESA driver is reasonably fast, it can't set the native display resolution on all systems, leading to a suboptimal Haiku experience.</p>
+<p>
+Nouveau is a graphics driver for NVidia video cards.
+</p>
+<p>Port (parts of) Nouveau to a Haiku graphic driver, allowing at least setting the native video mode. Hardware 3D acceleration may also be investigated, but requires more work on Haiku (see the next project idea).</p>
+
+<ul><li>
+        Skill set: kernel, and driver development
+</li></ul>
+-->
+
+
+<h4><img src="/images/Misc_OtherRenderer.png"/>GPU acceleration support</h4>
+<p>
+Haiku does not currently support GPU acceleration, for 3D or otherwise. Reusing
+most of the DRM drivers from Linux, and Mesa's Gallium userspace components,
+the goal of this project is to enable the use of GPU-accelerated OpenGL,
+and eventually also OpenCL and Vulkan.</p>
+
+<p>Haiku's current video drivers are mostly modesetting-only, and split in two parts: the driver itself, which is
+quite minimal and only provides low level access to the video card, and the
+"accelerant", which runs inside app_server and communicates with the driver
+in order to configure the card and use its features.</p>
+
+<p>Porting the DRM drivers from Linux will be a rather daunting task,
+as they use a large subset of the Linux kernel APIs. It may be possible
+to reuse OpenBSD's or DragonFlyBSD's work rather than writing our own
+Linux API compatibilty layer; more investigation is needed here.</p>
+
+<ul><li>
+        Skill set: kernel and driver development, Mesa graphics stack
+</li>
+<li>Possible mentors/knowledgeable people: waddlesplash, PulkoMandy</li>
+</ul>
+
+
+<a id="kernel" name="kernel"></a>
+<h3>Kernel</h3>
+
+<h4><img src="/images/App_Generic_32.png"/>
+Power Management
+</h4>
+
+<p>Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.</p>
+<p>Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:</p>
+<ul>
+<li>Some subsystems such as the network and wireless stack wake up the system at regular intervals (10 or 100 times per second) to perform some tasks. Whenever possible they should be modified to trigger these tasks in anevent-driven way (triggering them from hardware interrupts for example).</li>
+<li>Some applications (such as the always-running DeskBar) are polling for events in a similar way. The APIs should be adjusted where possible to make those applications wait on notifications instead.</li>
+<li>None of the device drivers in Haiku include powersaving modes. When a device is idle, it should be put to sleep and powered off until it is needed again.</li>
+
+<li>Skill set: kernel development, general C/C++, userland development, debugging, power management / measurement</li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>
+Improving the btrfs filesystem
+</h4>
+<p>Haiku has great support for its own file system, but most others are only
+available read-only. It is way better for interoperability with other systems
+to be able to write to these disks from Haiku.</p>
+
+<p>The goal of this project is to complete the btrfs filesystem, to allow it
+to write btrfs volumes (reading works already). During GSoC 2017 and 2018, students
+got as far as creating directories, but it is not possible yet to write
+files. The first part of the work is to review the existing code, and report on
+the current status and the work needed to get everything in place.</p>
+
+<p>After completion of this project, it should be possible to read and write
+files to btrfs volumes, making sure they are interoperable with Linux (mount
+without errors, file data is accessible, fsck detects no problems). Stress-testing
+should also be performed using bonnie++, and other test suites may also be used.</p>
+<ul><li>
+Skill set: kernel, and driver development
+</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy, Sean Healy, Hy Che</li>
+<li><a href="https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/btrfs">Sourcecode</a></li>
+<li><a href="https://www.haiku-os.org/blog/hyche">GSoC 2017 log</a></li>
+<li><a href="https://www.haiku-os.org/blog/brj">GSoC 2018 log</a></li>
+<li><a ref="https://review.haiku-os.org/q/status:open+btrfs">Existing btrfs patches to start from</a></li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Porting Apple NTFS driver to Haiku
+</h4>
+
+<p>Haiku currently supports NTFS using code from the NTFS-3G project, which is
+distributed under the GPL license. We would prefer to use Apple implementation,
+which is under 3 clause BSD, more suitable for us.</p>
+<p>Investigate the code in Apple NTFS driver and see how to map it to Haiku
+filesystem APIs, either by adding a compatibility wrapper (preferred, it makes
+updates easier), or by adjusting the NTFS code.</p>
+
+<ul><li>Skill set: filesystems, C, C++</li>
+	<li>Possible mentors: waddlesplash, PulkoMandy</li>
+	<li><a href="https://opensource.apple.com/source/ntfs/ntfs-94.200.1/">Apple NTFS sourcecode</a></li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>Adding write support for more filesystems</h4>
+
+<h5>Idea description</h5>
+
+<p>Some filesystems can only be read, but not written, from Haiku. The goal of this idea is to add write support for one of these filesystems (of your choice, from the list below).</p>
+
+<ul>
+<li><a href="http://en.wikipedia.org/wiki/Xfs">XFS</a> (<a href="http://xfs.org/index.php/Main_Page">Development community</a>, <a href="http://oss.sgi.com/projects/xfs/index.html">homepage</a>) is a filesystem originally developed for the IRIX operating system. Today it is commonly used by Haiku developers who build Haiku from Linux, because of its better support for extended filesystem attributes (unlike ext4).</li>
+<li><a href="http://en.wikipedia.org/wiki/Unix_File_System">UFS2</a> (<a href="https://github.com/freebsd/freebsd/tree/master/sys/ufs/ufs">FreeBSD implementation</a>, <a href="http://sourceforge.net/p/ufs2tools/code/HEAD/tree/trunk/ufs2tools/">u2fstools for windows</a>) is the default filesystem in FreeBSD, commonly used by some Haiku developers as well. It is closely based on the original Unix filesystem, which is implemented in many others operating system. The original design is quite simple, however the different implementations in various systems make it a bit more complex to handle all cases. Focus specifically on the FreeBSD variant is acceptable for this project if needed.</li>
+</ul>
+
+<h5>Why we need this</h5>
+
+<p>In its current state, Haiku is rarely used as the single operating system on a computer. It is common to dual boot it with other systems such as Linux or FreeBSD. In this setup, it is
+very convenient when each system can access and modify the other's files. Disk partitions and data can then be shared more easily.</p>
+
+<h5>Further details</h5>
+
+<ul><li>
+Skill set: data structures, C++
+</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy, waddlesplash, Hy Che</li>
+</ul>
+
+<!-- Removed for now, we have enough filesystems
+<h4><img src="/images/App_Generic_32.png"/>
+Adding a new filesystem to Haiku
+</h4>
+<p>Haiku has great support for its own file system, but is completely missing support for some other filesystems. It is way better for interoperability with other systems to be able to read and write to these disks.</p>
+<p>The goal of this project is to port one of the following filesystems to Haiku:</p>
+<ol>
+
+<li><a href="http://en.wikipedia.org/wiki/JFS_(file_system)">JFS</a>: existing code in Linux is under the GPL, a rewrite under the MIT license is preferred. The <a href="http://jfs.sourceforge.net/project/pub/jfslayout.pdf">filesystem design and disk structures</a> are well documented.</li>
+
+
+<li>HAMMER FS: <a href="http://www.dragonflybsd.org/hammer/">homepage</a>, <a href="http://fxr.watson.org/fxr/source/vfs/hammer/?v=DFBSD">sourcecode</a> (3-clause BSD, a port of the existing code is ok)</li>
+
+<li><a href="http://en.wikipedia.org/wiki/Zfs">ZFS</a>: <a href="http://www.open-zfs.org/wiki/Main_Page">main page</a>, <a href="https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/fs/zfs">existing code</a> (Existing code is under the CDDL, a rewrite is preferred)</li>
+</ol>
+<p>It's okay to port over the code from other systems, although we prefer code that can be distributed under the MIT license.</p>
+<p>It is recommended to start the work by getting an "fs_shell" building for the chosen filesystem. This is an userland tool that runs the filesystem code in a sandbox and provides a simple command prompt allowing to perform single, well controlled operations. Once the filesystem is usable in this mode, it can be integrated, first still running in userland with userland_fs, then later on running as a native kernel filesystem.</p>
+-->
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Filesystems benchmarking and stress-test
+</h4>
+
+<p>Some of the filesystems (or specific features of them) in Haiku are
+relatively new, and not considered perfectly tested and stable yet. The goal of
+this project is to define a procedure for testing the filesystems and identifying
+bugs (especially leading to on-disk data corruption) and performance bottlenecks.</p>
+
+<p>Tools like <a href="https://en.wikipedia.org/wiki/Bonnie%2B%2B">bonnie++</a>, <a href="https://github.com/kdave/xfstests">xfstests</a>,
+and the existing tests in src/tests/add-ons/kernel/file_systems in Haiku sources should be explored to determine their respective usefulness.
+Then, an automated way to run the tests should be defined (unit tests, integration tests on a running system, etc.)</p>
+
+<p>Then, the filesystems should be modified to fix the performance problems and/or bugs that were found in the process.</p>
+
+<ul>
+	<li>Skill set: C++ development, testing</li>
+	<li>Possible mentors/knowledgeable people: PulkoMandy</li>
+</ul>
+
+
+
+<h4><img src="/images/App_Generic_32.png"/>x86-64: Implement support for Process Context Identifiers (PCID)</h4>
+
+<p>on Intel CPUs. The feature tags TLB entries with the Id of the address space and allows to
+avoid TLB invalidation on the context switch, it is available only on x86-64.</p>
+<p>The goal of this task is to propose possible designs, implement the feature, extend the performance
+logs to measure impacts when the feature is enabled, and potentially also to mitigate the
+"Meltdown" vulnerability.</p>
+
+<ul><li>
+Skill set: kernel development, x86 architecture/assembly language
+</li>
+<li>Possible mentors/knowledgeable people: korli</li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>ARM port / device tree support</h4>
+
+<p>Unlike x86 systems which have a PCI bus, most ARM devices have peripherals at hardcoded addresses. This means automatic hardware discovery is not possible. The Linux kernel developers designed a solution called "flattened device tree". It is a static description of the hardware, telling the kernel where devices are located and which driver to use.</p>
+
+<p>Haiku plans to use device trees to support several ARM devices with the same kernel. This requires updating our drivers and driver infrastructure to not rely so much on the PCI bus. This work should start with the USB EHCI driver, in order to provide at least one mass storage solution to the ARM port of Haiku.</p>
+
+<p>The ARM port of Haiku is currently in an early state. This project may involve debugging of other issues in the port to get it running further, so the device tree part can be tested. Several parts of the early boot code should be reviewed to make use of the device tree and remove hardcoded addresses (RAM mapping, framebuffer, serial port, etc).</p>
+
+<ul><li>
+Skill set: kernel development, ARM architecture/assembly
+</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy, kallisti5</li>
+</ul>
+
+
+<!-- Mentors wanted
+<h4><img src="/images/App_Generic_32.png"/>Unify File System Caches</h4>
+
+<p>
+The Haiku kernel provides two kinds of caches for use by file system implementations: the <a href="https://cgit.haiku-os.org/haiku/tree/src/system/kernel/cache/file_cache.cpp">file cache</a> and the <a href="https://cgit.haiku-os.org/haiku/tree/src/system/kernel/cache/block_cache.cpp">block cache</a>. The file cache caches data at the "file" level, while the block cache is used at the "block" level and is used for on-disk structures as well as file data.</p>
+
+<p>The file cache uses physical memory pages directly and it is linked with the <a href="https://cgit.haiku-os.org/haiku/tree/src/system/kernel/vm">VM subsystem</a>, so that pages used for caching are freed automatically (in a least recently used order) when running low on free memory. The block cache, however, uses mapped memory (via the <a href="https://cgit.haiku-os.org/haiku/tree/src/system/kernel/slab">slab allocator</a>) and freeing memory in low memory situations is handled via the <a href="https://cgit.haiku-os.org/haiku/tree/src/system/kernel/low_resource_manager.cpp">low resource manager</a>.</p>
+
+<p>The first problem with the current implementation is caching imbalance in favor of the block cache: it tends grow more than needed and prevent the file cache to get enough memory.</p>
+<p>Another problem is the use of large amounts of kernel address space by the block cache, which can be problematic on 32 bit architectures. This makes the block cache constrained to the 2GB of memory available for the kernel in Haiku, and sometimes makes the kernel run out of address space for other uses.</p>
+
+<p>The goal of this project is to create a common underlying mechanism (using `VMCache`) to unify both caches and move the block cache out of the kernel address space. The following problems need to be investigated and solved:
+<ul>
+<li>How to deal with heterogenous block sizes (not necessarily matching the page size): each mounted filesystem volume may have a different block size, and the block cache must be able to efficiently cache blocks of these different sizes,
+<li>How to map support for transactions to `VMCache` hierarchies,
+<li>Balancing of the memory allocation between the block and the file cache and between multiple mounted filesystem volumes.
+</ul>
+</p>
+<ul><li>
+Skill set: kernel development
+</li></ul>
+-->
+
+
+<a id="network" name="network"></a>
+<h3>Network</h3>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Bluetooth Stack Improvements
+</h4>
+<p>Haiku's Bluetooth stack implements a basic subset of general Bluetooth functionality. This functionality needs to be
+completed and Bluetooth 2.X and later possibilities explored. This task involves investigating the current state of the
+Bluetooth code, improving the existing code on newer devices (pairing, etc), and improving the stack
+to make it more useful by implementing driver(s) for Bluetooth device(s) of your choice (file transfers, audio, HID,
+networking, etc).</p>
+
+<ul>
+<li>Requirements: Bluetooth-enabled Haiku system</li>
+<li>Skill set: C++, kernel development, userland development, global bluetooth stack knowledge (optional)</li>
+<li>Possible mentors/knowledgeable people: waddlesplash <!-- also possibly PulkoMandy --></li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"\>
+VPN Support
+</h4>
+<p>With the decline of internet freedoms (Government IP Blocks, Net Neutrality reductions), the usage of encrypted virtual
+networks is increasing across all platforms.  Haiku's VPN implementation is severly lacking.  To improve global access
+to Haiku as a desktop platform of choice, our VPN support needs a lot of work. OpenVPN or Wireguard are both great options.</p>
+
+<ul>
+<li>Requirements: Internet connected Haiku system</li>
+<li>Skill set: C++, kernel development, userland development, TCP/IP stack understanding</li>
+<li>Possible mentors/knowledgeable people: kallisti5 <!-- also possibly PulkoMandy, waddlesplash --></li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>
+Integrate our PPP implementation
+</h4>
+<p>Finish porting the PPP implementation to our new network stack. Add phone-line modem support, including HDLC
+framing and VJC compression (porting both algorithms is sufficient, but make sure the license is compatible to MIT).
+Implement CHAP authentication, and add support for configuring these to the new network preflet GUI. Find and fix bugs.</p>
+
+<ul>
+<li>Tickets: <a href="https://dev.haiku-os.org/ticket/812">#812</a>, <a href="https://dev.haiku-os.org/ticket/869">#869</a>, <a href="https://dev.haiku-os.org/ticket/873">#873</a>, <a href="https://dev.haiku-os.org/ticket/922">#922</a>, <a href="https://dev.haiku-os.org/ticket/923">#923</a>, <a href="https://dev.haiku-os.org/ticket/1059">#1059</a>, maybe: <a href="https://dev.haiku-os.org/ticket/1057">#1057</a>, <a href="https://dev.haiku-os.org/ticket/1058">#1058</a></li>
+<li>Skill set: multi-threading basics, maybe network protocols and some kernel/drivers development, maybe UI development</li>
+</ul>
+
+<!--
+
+<h4><img src="/images/App_Generic_32.png"/>
+Stream Control Transmission Protocol (SCTP)
+</h4>
+<p>Implement and test SCTP, a message based transport layer protocol similar to TCP and UDP. It should comply with current IP and IPv6 implementations and provide similar programming API as BSD.</p>
+<ul>
+<li>Skill set: network protocols, kernel and network stack development</li>
+</ul>
+-->
+
+<h4><img src="/images/App_Generic_32.png"/>
+IPv6 finalization
+</h4>
+<p>
+The base framework for IPv6 support was implemented as a Google Summer of Code 2010 project. Even so, there remains a lot of
+smaller cleanup/finalization tasks that can be done as a project.
+</p>
+<ul>
+<li>Tickets:
+<ul>
+<li><a href="https://dev.haiku-os.org/ticket/8293">#8293</a> -- BNetworkAddress needs to check if there is an available IPv6 connection.</li>
+<li><a href="https://dev.haiku-os.org/ticket/7228">#7228</a> -- RFC: BNetworkInterfaceAddress needs to store auto-configuration flags</li>
+<li><a href="https://dev.haiku-os.org/ticket/6489">#6489</a> -- ifconfig needs to validate availability of ipv6 module prior to utilization</li>
+<li><a href="https://dev.haiku-os.org/ticket/2632">#2632</a> -- Possible redefinition for struct sockaddr_in, related to IPv6</li>
+<li><a href="https://dev.haiku-os.org/ticket/8319">#8319</a> -- Haiku needs IPv6 duplicate address detection during link scope ip configuration.</li>
+<li><a href="https://dev.haiku-os.org/ticket/8317">#8317</a> -- Haiku needs IPv6 global scope Auto Configuration (router advertisement + DHCPv6)</li>
+<li><a href="https://dev.haiku-os.org/ticket/11862">#11862</a> -- Net server multi-protocol rework</li>
+</ul>
+</li>
+</ul>
+
+<ul>
+<li>Skill set: IPv4 and IPv6 protocols, kernel and network stack development</li>
+<li>Possible mentors: jua</li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>MDNS / Bonjour / Avahi network discovery</h4>
+
+<h5>Idea description</h5>
+
+<p>MDNS (known as Bonjour for Apple devices and usually implemented using Avahi on Linux) is a protocol allowing to discover devices in the local network and their capabilities. The goal of this project is to implement MDNS in Haiku and integrate it in our name resolution system and user interface.</p>
+
+<h5>Why we need this</h5>
+
+<p>MDNS is part of the IPP Everywhere and Airprint specifications, which allow to use networked printers with a single generic driver, instead of a specific driver for each printer. Having an implementation in Haiku would allow easier setup and use of printers, a required feature for a desktop operating system.</p>
+
+<h5>Further details</h5>
+
+<ul>
+	<li>Skill set: network programming (UDP, IPv4, multicast)</li>
+	<li>Possible mentors: PulkoMandy</li>
+</ul>
+
+<a id="user-interface" name="user-interface"></a>
+<h3>User Interface</h3>
+
+<!-- removed: needs to be thought out on the mailing list a little better
+<h4><img src="/images/App_Generic_32.png"/>
+Preferences GUI refactoring
+</h4>
+<p>
+Haiku is an operating system designed for ease of use on desktop computers. A key part of this work is an easy to use set of preference applications. Some of the currently available preference panels could be merged or improved in several ways.</p>
+<p>
+Several preference applications (aka preflets) could be redesigned. Furthermore, there might still be code that does not yet use our layout API. This work may include (but is not limited to):</p>
+<ol>
+<li>combining Keymap, Keyboard, Mouse and Touchpad in a single "Input devices" preferences panel,</li>
+<li>adding support for joysticks and touch screens support to it,</li>
+<li><a href="https://dev.haiku-os.org/ticket/6983">#6983</a>Reworking the Printer preferences to look better and be more intuitive.</li>
+<li><a href="https://dev.haiku-os.org/ticket/6206">#6206</a>integrate scrollbar options into a new Appearance preflet, and provide a live preview for all of the settings available in this window</li>
+<li>Improving the user interface of the shortcuts preference to make it easier to setup custom shortcuts</li>
+<li>Improving and extending the notifications preferences to allow easy control of allowed notifications, browsing of the notification history.</li>
+<li>Research on how to improve the other preference panels further with the goal of making them easier to use.</li>
+</ol>
+<ul>
+<li>Skill set: C++, UI development, usability basics</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy, waddlesplash</li>
+</ul>
+-->
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Modular edit view (BIG)
+</h4>
+
+<p>The current solution for text editing in Haiku is the BTextView. It is a
+rather simple view providing basic text editing features and limited styling.
+This is, however, not powerful enough for most serious uses. The goal of this
+project is to design a complete replacement for BTexView, which should be designed
+to cover more use cases.</p>
+
+<p>The edit view design should be modular and extensible to make it easy to implement e.g. following features:
+<ul>
+<li>spell checker</li>
+<li>line numbers, ruler, 80 character limit line, hyper links</li>
+<li>working on an input stream rather than on a input file e.g. to be able to open files ~100Mb without loading them into memory in one go</li>
+<li>Including pictures in the text flow</li>
+<li>Sourcecode editor: syntax highlighting, code completion</li>
+<li>Ability to load and save data in different formats (using the Translation Kit)</li>
+</ul>
+</p>
+
+<h5>Existing work</h5>
+<p>The HaikuDepot application includes preliminary work on a rich text view,
+which it uses to provide the description of packages. This could be used as a
+starting point for this work.</p>
+
+<ul>
+	<li>Skill set: C++, API design, UI development</li>
+	<li>Possible mentors: waddlesplash, Sean Healy, scottmc</li>
+</ul>
+
+
+<a id="media" name="media"></a>
+<h3>Media</h3>
+
+<!-- needs to be discussed more; working on a MediaKit2 may make more sense. (Didn't Dan0 have MediaKit2?)
+<h4><img src="/images/App_Generic_32.png"/>Add subtitle support to the Media Kit</h4>
+
+<p>Haiku "media" applications rely on a framework called the Media Kit. This
+provides an unified API to handle audio and video streams, including codec
+plugins to read and write the stream to files or other sources, as well as
+transporting the data from one application to another, with a latency as low as
+possible.</p>
+
+<p>While our MediaPlayer has support for external subtitle files, the Media Kit
+itself has not. The most obvious downside of that is that there is no support
+for subtitle (text or bitmap) embedded in video files within the MediaPlayer or
+other applications.</p>
+
+<p>Your job would be to design the necessary API extensions to let subtitles fit
+in with the rest of the Media Kit, and add native support for them, which will
+then be available to all applications as part of the framework.</p>
+
+<ul>
+<li>implement the required code to extract the subtitles from source files
+(either standalone .srt files or contained for example in mkv containers), with
+proper handling of replay time and text encoding</li>
+
+<li>integrate this in the existing API (probably as a new kind of BMediaTrack),
+and update applications such as MediaPlayer and MediaConverter to make use of
+the feature.</li>
+
+<li>See <a href="/legacy-docs/bebook/TheMediaKit_Overview_Introduction.html" target="_blank">
+the BeBook introduction for the Media Kit</a> to become familiar with its design.</li>
+
+<li>Skill set: general C/C++, userland development, API design</li>
+<li>Possible mentors: Barrett, jua, PulkoMandy</li>
+</ul>
+-->
+
+<h4><img src="/images/App_Generic_32.png"/>Complete and Finalize the MediaPlayer Plugin API</h4>
+
+<p>The MediaPlayer app included in Haiku is able to play most of the media
+formats around. To be able to do that it includes a monolithic framework that
+uses most of the important features of the media_kit. To improve maintainability
+and flexibility we are looking forward to include a plugin API and export or
+implement as plugins certain functionalities.</p>
+
+<p>
+Some examples :
+<ul>
+	<li>Playlist</li>
+	<li>Attributes editor</li>
+	<li>Cover Art</li>
+	<li>Web Remote Control</li>
+</ul>
+</p>
+
+<p>
+Some efforts have been already put and can be found <a href="https://github.com/Barrett17/haiku/tree/mediaplayer_plugin_api">here</a>.</p>
+
+<p>Other Links:
+
+<ul>
+	<li><a href="https://www.haiku-os.org/legacy-docs/bebook/themediakit_overview">Media Kit overview (the Be Book)</a></li>
+	<li><a href="https://api.haiku-os.org/group__media.html">Media Kit overview (the Haiku Book)</a></li>
+</ul>
+</p>
+
+<ul>
+	<li>Skill set: general C++, userland development, software design</li>
+	<li>Possible mentors: Barrett</li>
+</ul>
+
+
+<!--
+<h4><img src="/images/App_Generic_32.png"/>
+Implement system wide and application level input/output chooser
+</h4>
+<p>
+When more than one soundcard is attached to Haiku, you can only change the default input/output in the Media preferences, or reconnect media nodes manually via Cortex to another input/output device.
+The Media Kit could support default nodes per application (either unset (system default), or set to a specific device), and the Media preferences could offer an UI to change this.
+</p>
+<p>
+Additionally, applications like MediaPlayer, and SoundRecorder should be able to change the input/output device within the application, too (which would just be another way to alter the described Media Kit functionality).</p>
+<p>This functionality should only be visible if there actually is more than one audio device attached to the system; if a device is not available, it should automatically use the default output instead.
+</p>
+<p>
+Part of this work would be to implement non-volatile storage that the Media Kit uses for each application that is connected to it, and the ability to detect the application on next start. This storage could then also be used to remember other per application sound settings in the future (or if time permits) like the balance, and relative volume.
+</p>
+
+<ul>
+<li>Skill set: general C/C++, userland development</li>
+<li>Possible mentors: jua</li>
+</ul>
+-->
+
+
+<!--
+<h4><img src="/images/App_Generic_32.png"/>Improving Clockwerk</h4>
+
+<p>Clockwerk is a video editing bench for Haiku. It works well, but it is a bit
+unstable and the feature set is not that complete.</p>
+- TODO complete the description -
+<ul>
+	<li>Possible mentors: jua</li>
+</ul>
+-->
+
+<a id="ports" name="ports"></a>
+<h3>Ports</h3>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Porting the Go Programming Language to Haiku
+</h4>
+
+<p>Go (or Golang) is a popular cross-platform general-purpose programming language which is known for its direct compilation to static executables, concurrency model used in its goroutines and its enforced standard style of programming. It has been used by many developers to create command-line tools, static site generators, high-performance servers and many other applications requiring Go.
+
+<h5>Existing work</h5>
+
+There was a previous GSoC student who originally ported Go 1.3 to Haiku, but unfortunately it was unmaintained and was broken over the years. In 2018, the port was later updated to Go 1.4.3 but only for 64 bit. Work has been attempted in bootstrapping higher versions like 1.5 and 1.11 but the bootstrap process have produced binaries that are broken and don't work.
+
+The goal of this project is to identify the issue preventing the bootstrap process from completing and then attempt to fully build either a recent version (Go 1.11) or the latest version of Go only using Go 1.4.3 for 64 bit.
+
+<em>Please note that this port may require diving into the low-level components of the compiler and Haiku internals rather than primarily programming in Go.</em>
+
+<p>Links:
+<ul>
+	<li><a href="https://github.com/golang-haiku/go/tree/golang-1.11-haiku">Go 1.11 Haiku port (GitHub)</a></li>
+	<li><a href="https://github.com/golang-haiku/go-1.4.3">Go 1.4.3 port (Bootstrapper)</a></li>
+		<li><a href="https://bitbucket.org/zhuowei/go-1-3-haiku/src/default/">Previous GSoC Go port (Bitbucket)</a></li>
+</ul>
+</p>
+
+<ul>
+	<li>Skill set: C, Go, Go assembly, low-level programming, ELF-internals </li>
+	<li>Possible mentors: return0e, BGA</li>
+</ul>
+
+<a id="other" name="other"></a>
+<h3>Other</h3>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Jam (build system) replacement/rewrite
+</h4>
+<p>Haiku uses Jam as its main build system. Unfortunately, Perforce is not actively
+maintaining the tool anymore and the codebase is not very clean. Ingo Weinhold
+started work on <a href="https://github.com/weinhold/ham">a complete rewrite</a> of the tool in C++, with the aim of being
+compatible with the existing build files, but provide a cleaner codebase to
+build upon and do away with most of the legacy stuff.</p>
+<p>The goal of this project is to continue this work and make ham usable to build
+Haiku, as well as other projects currently using Jam as a buildtool.</p>
+<ul>
+	<li>Skill set: C++, threading, build systems</li>
+	<li>Possible mentors: waddlesplash</li>
+</ul>
+
+<h4><img src="/images/App_Generic_32.png"/>
+Coding style checker bot for Gerrit
+</h4>
+<p>Haiku has its own <a href="/development/coding-guidelines/">coding guidelines</a>
+which describe how the code should be formatted. There is <a href="https://github.com/owenca/haiku-format">a tool</a> for reformatting
+or checking if code follows these guidelines, but it has to be compiled on the
+developer machine and then run manually.</p>
+<p>The goal of this project is to integrate this tool with Gerrit, the web app
+we use for code reviews. It could then give quick feedback on the coding style
+as soon as a patch is submitted, making the review process smoother and easier.</p>
+<p>Ideally, the changes could be run through a specific concourse configuration,
+which would run haiku-format, and then post the result as comments in Gerrit pointing out the lines that need to be fixed, and give a review score to the change.</p>
+<ul>
+	<li>Skill set: REST APIs, code formatting tools</li>
+	<li>Possible mentors: PulkoMandy</li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Add Haiku support to Allegro 5.0
+</h4>
+<p>Allegro is a gaming library. Older version (4.4) did support Haiku, but this
+support was dropped from the newer versions (starting from 5.0). The library
+should be ported to Haiku, allowing to run the bundled examples and possibly
+port some other software using it.</p>
+
+<ul>
+	<li>Skill set: C++, userland development</li>
+	<li>Possible mentors: scottmc</li>
+	<li>Alternative projects: porting SFML or another similar library</li>
+</ul>
+
+
+<!-- REMOVED: needs more thinking on Haiku side to decide on a plan for this.
+
+<h4><img src="/images/App_Generic_32.png"/>
+Modify the app_server to support compositing
+</h4>
+<p>This would be a step towards faster/smoother scrolling, window positioning and drawing. Once compositing is in place, it would also be possible to create Compiz-like effects in Haiku, eg. drop shadows, transparent windows, content previews, and window animations.</p>
+<p>There's lots of info on what would need to be done and how to go about it in this article: /articles/2011-06-15_how_transform_app_server_code_use_compositing .</p>
+<ul>
+<li>Skill set: C++, graphics development</li>
+</ul>
+-->
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+Multiple monitors output in app_server
+</h4>
+<p>app_server is Haiku's graphics server and the equivalent of X11 or Wayland on other UNIX systems. It currently supports only one video output, but should be able to do more.</p>
+<p>While the API already allows this for the most part (with the BScreen class), there is no actual implementation behind it and parts of the code assume only a single screen.</p>
+<p>Some drivers implement minimal support for multiple displays, but not all of them. This task may involve updating the video drivers to handle multiple monitors correctly.</p>
+<ul>
+<li>Skill set: C++, graphics development</li>
+<li>Possible mentors/knowledgeable people: jua, PulkoMandy</li>
+</ul>
+
+
+<h4><img src="/images/App_Generic_32.png"/>
+	Complex font rendering in app_server
+</h4>
+<p>app_server is the graphics server in Haiku. It handles the rendering and
+display of application windows, desktop, and everything that is shown on screen.</p>
+<p>Freetype (in combination with agg) is used to render text. While it provides
+good results on its own for latin and cyrillic alphabets, Freetype is not enough
+on its own to properly render other scripts with more complex rules, such as
+Devanagari or Arabic.</p>
+<p>The goal of this task is to integrate Harfbuzz into app_server, so that the
+complex rules for text rendering are properly applied. This would allow rendering
+of complex languages as mentioned above, as well as mixing different languages
+(picking appropriate fonts automatically).</p>
+<p>This task can be further extended with investigations of API changes required
+in the interface kit (and in particular BView and BFont) to properly handle left
+to right text.</p>
+
+<ul>
+	<li>Skill set: C++</li>
+	<li>Possible mentors: stippi, PulkoMandy</li>
+</ul>
+
+<!--
+<h4><img src="/images/App_Generic_32.png"/>
+RTL languages support in interface kit
+</h4>
+<p>The interface kit is the part of the API taking care of everything drawing related: windows, buttons, and other widgets. It is not currently able to display right-to-left languages (such as arabic) properly, making Haiku unusable for a lot of people.</p>
+<p>Font rendering should be reworked to use the HarfBuzz library, instead of just Freetype, providing support for ligatures and bidirectional text output. The Layout Kit (which handles positionning widgets in a window) should be made to work as expected with these languages (possibly inverting left and right in the window layout).</p>
+<p>This task can be extended with better support for font overlays (picking the correct font for each language automatically, probably using fontconfig), and work on input methods for some languages.</p>
+<ul>
+<li>Skill set: C++, graphics development, text rendering</li>
+<li>Possible mentors/knowledgeable people: PulkoMandy</li>
+</ul>
+-->

content/community/gsoc/2021/students.html

@@ -0,0 +1,235 @@
++++
+type = "article"
+title = "Students"
+date = "2020-01-13T19:04:24.000Z"
+tags = []
++++
+
+<h3>Student Application Mini-FAQ</h3>
+<ul>
+<li><strong>Where do I apply?</strong>
+	<br />Start from the <a href="https://summerofcode.withgoogle.com/">Google Summer of Code site</a></li>
+<li><strong>What ideas can I apply for?</strong>
+	<br />Check out our <a href="/community/gsoc/2020/ideas">List of Google Summer of Code Ideas</a></li>
+<li><strong>What info do you need in the application?</strong>
+	<br />See the <a href="#template">Application Template</a> below for reference</li>
+<li><strong>What if I still have questions?</strong>
+	<br />Send a message to the <a href="http://www.freelists.org/list/haiku">Haiku Mailing List</a> or contact Haiku's <i>Google Summer of Code</i> administrator (<a href="https://discuss.haiku-os.org/users/pulkomandy">PulkoMandy</a>).</li>
+
+<li><strong>Are there any other requirements?</strong><br />
+
+<strong>Applying students are required to submit a code contribution</strong> to
+our <a href="https://review.haiku-os.org/">change review tool</a>. This could either be a
+<a href="https://dev.haiku-os.org/query?status=assigned&status=new&status=reopened&summary=~easy">task marked easy</a>,
+<a href="https://xref.landonf.org/source/search?q=TODO&defs=&refs=&path=&hist=&project=haiku">TODO commented in code</a>,
+<a href="/development/coding-guidelines">code style cleanup</a>, or any other
+unlisted task. Submitting code that relates to your project will indicate a
+higher level of understanding and ability. The number and difficulty of resolved
+issues will be taken into consideration when evaluating your application. It is
+suggested to <strong>set the topic to "gsoc2020" on submissions</strong>,
+as this facilitates finding them in the future.</li>
+
+<!-- TODO link to queries for past year submissions, to show it is not that hard -->
+
+<li><strong>Why do you want a code contribution before I'm accepted?</strong><br />
+
+This serves several purposes. It displays that you have the most basic skills
+that are required: building Haiku from source, running Haiku either natively or
+inside a VM, and using tools for online collaboration (bug tracker, mailing
+lists, IRC, etc.). More importantly, it provides our mentors with some insight
+into each individual student's motivation and abilities. It is an opportunity
+for you, the student to showcase yourself and to convince us that you are indeed
+the right person for the job.
+<br/>
+The code contribution is a very important part of your application.
+<strong>Students who did not submit one, or submit something insufficient, will
+not be accepted into the program.</strong>
+
+</li>
+<li><strong>Should I use Haiku R1/beta1 or a newer nightly image?</strong><br />
+As a developer, you will be working with the most recent code and test your changes
+on the development branches, so a nightly image is recommended. You can use
+either a 32bit or 64bit one, as you prefer.
+</li>
+</ul>
+
+<a id="impress" name="impress"></a>
+<h3>Making a Positive Impression</h3>
+<p>In open source work, communication is the key. You will be working remotely, and will need to communicate with your mentor, and other members of the Haiku community, over the Internet. Show us you're able to work this way and interact with other Haikuers in a productive and efficient way.</p>
+<ul>
+<li><a href="https://dev.haiku-os.org/wiki/SubmittingPatches">Submit a patch</a>:
+<ul>
+<li><strong>that relates to your project</strong></li>
+<li>is quality code that conforms to our <a href="/development/coding-guidelines">Coding Guidelines</a></li>
+<li>feel free to submit more than one patch!</li>
+</ul>
+<li>Have a positive impact on mailing lists, <a href="https://dev.haiku-os.org">bug tracker</a>, and other public spaces</li>
+<li>Do your homework ; Show that you have:
+<ul>
+<li>researched your project</li>
+<li>an understanding of what needs to be done</li>
+<li>a proper plan for accomplishing it, which includes quantifiable goals and timelines</li>
+</ul>
+</li>
+<li>Submit an alternate proposal, as this provides our mentors with flexibility for choosing the best students, rather than the best project ideas</li>
+</ul>
+
+<a id="advice" name="advice"></a>
+<h3>Words of Advice</h3>
+<p>
+Reading and following this advice will do wonders for ensuring
+that your <i>Google Summer of Code</i> experience will be something to be proud of.
+</p>
+
+<ol>
+<li><strong>Dedicate at least 30 hours per week</strong><br />
+  As <i>Google Summer of Code</i> is essentially a work-from-home internship,
+  you are expected to put in the necessary time. To note, the majority of
+  Haiku's students who spent less than 30 hours per week, failed.
+</li>
+
+<li><strong>Communicate every other day</strong><br />
+  The haiku-gsoc mailing list is to be used at all times by you.
+  Provide regular reports. Nothing formal, just one or two lines.
+  It is important for your mentors to have a clear picture of what you are doing, have done, and plan to do.
+  While being self-sufficient is a worthwhile trait, it is not an ideal trait for a Google Summer of Code participant -- Haiku expects you to utilize our mentors, that is why they are there.
+</li>
+
+<li><strong>Provide code frequently</strong><br />
+  There is a saying in open source -- commit often, commit frequently.
+  Take that advice to heart.
+  Smaller patches and code snippets are easier for the mentors to review.
+  It also gives them more chances to suggest better approaches and keep you on target.
+  In turn, this will make you more productive and more likely to succeed!
+  You can put your work in progress changes in our code review tool so your mentor and other developers can help you spot the problems. It is perfectly fine to share non-working code, in fact a lot of the changes listed in the code review tool are in this case and several iterations will be needed to get things right.
+</li>
+
+<li>
+<strong>When you do not have code, it is even more critical to converse frequently.</strong><br />
+  If you aren't coding, what are you doing?
+  How are you moving closer to your goal?
+  What problems are you analyzing?
+  What questions and ideas do you have?
+  Every year, many students get stuck on an issue and spend too much time trying to solve it by themselve, when a mentor could help them progress much faster. This isn't a school assignment, we will not fail you for asking too much questions.
+</li>
+
+</ol>
+
+<a id="passorfail" name="passorfail"></a>
+<h3>Pass or Fail Criteria</h3>
+
+<p>As you know, <i>Google Summer of Code</i> has three monthly evaluation points.
+If you happen to receive
+a failing mark at either point, you are not paid that portion and your
+internship comes to an abrupt end. There are two areas
+that are considered during the evaluation: the code output and
+communication/interactions.
+</p>
+
+<p>
+  A word of caution -- do not expect to make miracles during the week
+  of mid-term or final evaluations. Instead, expect your mentor to
+  evaluate your progress on the first day of the window.
+</p>
+
+<ol>
+<li><strong>Code.</strong><br />
+  This includes everything from 'commit worthy' patches to all the code
+  (and non-code, such as design documents or pseudo code) leading up to
+  that polished patch. In other words, if for some reason you and your
+  mentor pursue an approach that turns out to be a dead end you will not
+  be punished.
+</li>
+
+<li><strong>Communication.</strong><br />
+  This includes discussions on the haiku-development list,
+  talking with haiku developers on IRC,
+  posting the Milestone Blog/Email Reports.</li>
+</ol>
+
+<p>
+  In other words, <strong>you will be writing code and talking with
+  one or more mentors on a daily basis.</strong> Anything less will
+  hurt your mid-term and final evaluation! Do not expect to be able
+  to cram days, weeks, or months of work into a shorter period and
+  receive a passing evaluation.
+</p>
+
+<a id="template" name="template"></a>
+<h3>
+Application Template
+</h3>
+<p>This application template has two sections.</p>
+<ol>
+<li>A fill-in-the-blank section with basic information.</li>
+<li>An open-ended section with suggestions for content to include. Feel free to add more.</li>
+</ol>
+<hr>
+<h4>(Fill in)</h4>
+<ul>
+<li>Full name:</li>
+<li>Timezone:</li>
+<li>Email address:</li>
+<li>IRC username (freenode.net):</li>
+<li>Trac username (dev.haiku-os.org):</li>
+<li>Gerrit changes submitted (review.haiku-os.org):</li>
+<li>(optional) GitHub (or other public) repository:</li>
+<li>(optional) emergency contact (please include contact information for someone we can get in touch with if something makes you unable to continue your project and you can't give any news to us):</li>
+
+<li>Will you treat <i>Google Summer of Code</i> as full time employment?</li>
+<li>How many hours per week will you work?</li>
+<li>List all obligations (and their dates) that may take time away from GSoC (a second job, vacations, classes, ...): </li>
+<li>Are you using <i>Google Summer of Code</i> to fullfill a university requirement -- internship, class credit, ..? (If yes, you need to provide confirmation that your school approves. Remember, <i>Google Summer of Code</i> is a remote software development internship.)</li>
+<li>How and when did you first heard about Haiku?</li>
+<li>Did you also apply to other GSoC organizations? If so, which is your order of preference? (this has no impact on the selection process, we use this information only if you are selected as an intern by several of these organizations to decide which one would keep you)</li>
+<li>Estimated last day of classes/exams:</li>
+<li>Estimated first day of classes (for most interns, there will be some overlap with the GSoC coding period. This is fine, but we want to check that you have planned your timeline accordingly):</li>
+</ul>
+
+<h4>(Open-ended)</h4>
+<ol>
+<li>Introduce yourself. (Who you are. Why you chose Haiku. What programming experience you have.)</li>
+<li> Project Proposal. (Title. Description. Goals.)</li>
+<li> Timeline. Include what you plan to have accomplished by the end of:
+<ul>
+  <li>Community bonding period (May)</li>
+  <li>First month of coding (June)</li>
+  <li>Second month of coding (July)</li>
+  <li>Third month of coding (August)</li>
+  <li>After Google Summer of Code</li>
+</ul></li>
+<li>Expectations from Mentors. (What do you expect Haiku's mentors to help you with?)</li>
+</ol>
+
+<hr>
+
+<p>If you have questions about your application for a Haiku idea, please contact Haiku's <i>Google Summer of Code</i> administrator (<a href="https://discuss.haiku-os.org/users/pulkomandy">Adrien Destugues</a>), or send an email to the <a href="http://www.freelists.org/list/haiku">Haiku mailing list</a>.</p>
+
+<h3>Resources available to students</h3>
+<p>
+In addition to the mentor(s) assigned to each student, the following resources will be available where inquiries can be made in order to get assistance during your <i>Google Summer of Code</i> project.
+</p>
+<ul>
+<li class="icon-folder-mail"><strong>Mailing list:</strong> <a href="http://www.freelists.org/list/haiku">Subscribe here</a></li>
+<li class="icon-folder-people"><strong>IRC channel:</strong> <a href="irc://chat.freenode.net/%23haiku">#haiku@chat.freenode.net</a> (<a href="http://webchat.freenode.net/?channels=haiku">browser-based client</a>)</li>
+<li class="icon-folder"><strong>Haiku Guides:</strong>
+	<ol>
+	<li><a href="https://cgit.haiku-os.org/haiku/plain/ReadMe.md">An introduction to the Haiku project</a></li>
+	<li><a href="https://cgit.haiku-os.org/haiku/plain/ReadMe.Compiling.md">Building Haiku from source</a> (single plain text file)</li>
+	<li><a href="/guides/building">Building Haiku from source</a> (html)</li>
+	<li><a href="/guides/installing">Installing Haiku</a></li>
+	<li><a href="/documents/dev/a_brief_introduction_to_our_source_repository_layout">A Brief Introduction to our Source Repository Layout</a></li>
+	<li><a href="/development/coding-guidelines">Coding Guidelines</a></li>
+	<li><a href="https://dev.haiku-os.org/wiki/SubmittingPatches">Submitting a patch to Haiku</a></li>
+
+</ol></li>
+
+</ul>
+
+<h3>For more information</h3>
+
+<p>For more information about general information and eligibility for <i>Google Summer of Code</i> 2020, please check out the following Google resources:</p>
+<ul>
+<li class="icon-html"><a href="https://developers.google.com/open-source/gsoc/resources/">Google Summer of Code Resources</a></li>
+<li class="icon-html"><a href="http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/">GSoC Student Guide: What is Google Summer of Code?</a>.</li>
+</ul>

content/community/software.md

@@ -8,11 +8,10 @@ tags = []
 <p>Here's a list of sites providing 3rd party software for Haiku. Some offer a direct download of HPKG packages or zip archives, others have a repository which you can add to Haiku with the "Repositories" preference panel.</p>
 
 <ul>
-<li><a href="http://www.be.wildman-productions.org/">BeBytes - The BeOS Software Archive</a>: A software archive like the old BeBits in BeOS times.</li>
+<li><a href="https://www.be.wildman-productions.org/">BeBytes - The BeOS Software Archive</a>: A software archive like the old BeBits in BeOS times.</li>
 <li><a href="https://www.software.besly.de/">BeSly Software Repo</a>: A repository for Haiku software.</li>
-<li><a href="http://clasquin-johnson.co.za/michel/haiku/repo/index.html">Clasqm's repo</a>: A repository with a huge collection mainly of packaged BeOS applications, but also new Haiku software, documentation, fonts, demos and other things.</li>
-<li><a href="http://fatelk.com/repo">Fat Elk Software</a>: A repository Fat Elk's own and other 3rd party software.</li>
-<li><a href="http://pulkomandy.tk/~beosarchive/about.html">PulkoMandy's BeOS software archive</a>: A software archive of old BeOS software, with and without source code.</li>
+<li><a href="https://fatelk.com/">Fat Elk Software</a>: A repository Fat Elk's own and other 3rd party software.</li>
+<li><a href="https://pulkomandy.tk/~beosarchive/about.html">PulkoMandy's BeOS software archive</a>: A software archive of old BeOS software, with and without source code.</li>
 <li><a href="http://softwaredepot.altervista.org/">Software Depot</a>: A software archive of packaged Haiku software.</li>
 </ul>
 

content/documents/_index.md

@@ -33,6 +33,7 @@ These are legacy BeOS documents released as reference material for those who wan
 
 * [The BeBook](/legacy-docs/bebook/index.html)
 * [The Be Newsletters](/legacy-docs/benewsletter/index.html)
+* [The OpenBeOS Newsletters](/legacy-docs/openbeosnewsletter/index.html)
 
 ### Other Resources
 
@@ -46,4 +47,3 @@ These are legacy BeOS documents released as reference material for those who wan
 ## Contributed Articles
 
 The Haiku community has contributed a large number of [detailed articles](/articles) over the years, be sure to check them out!.
-

content/documents/dev/building_haiku_ubuntu_linux_step_step.md

@@ -39,12 +39,12 @@ the build tools (be sure to adjust the options to match your build environment):
 **Working in a clean build directory:**
 ```sh
 mkdir generated.x86_64; cd generated.x86_64
-../configure --build-cross-tools x86_64 ../../buildtools
+../configure --cross-tools-source ../../buildtools --build-cross-tools x86_64
 ```
 
 **Working in the top level:**
 ```sh
-./configure --build-cross-tools x86_64 ../buildtools
+./configure --cross-tools-source ../buildtools --build-cross-tools x86_64
 ```
 
 x86_64 Haiku Builds

content/documents/dev/getting_linux_developer_tools.html

@@ -54,14 +54,14 @@ tags = ["obsolete"]
 
 <p>2.95:<br /></p>
 
-<pre>cd haiku <br />./configure --build-cross-tools ../buildtools/</pre>
+<pre>cd haiku <br />./configure --cross-tools-source ../buildtools/ --build-cross-tools x86_gcc2</pre>
 
 <p>4.x</p>
 
-<pre>cd haiku<br />./configure   --build-cross-tools-gcc4 x86 ../buildtools/</pre>
+<pre>cd haiku<br />./configure --cross-tools-source ../buildtools/ --build-cross-tools x86</pre>
 
 <p>The process can take quite some time, but when it finishes you are ready to compile your first haiku image.<br /></p>
         </div>
         </div>
 </div>
-  
+  

content/guides/building/compiling-arm.md

@@ -17,17 +17,46 @@ Building the ARM compiler toolchain is quite easy using Haiku's ```configure```
 
 1. Perform a git clone haiku and buildtools
 2. Within the haiku source directory, create your workspace for ARM via ```mkdir generated.arm; cd generated.arm```
-2. Leverage configure to build your ARM toolchain. ```../configure -j2 --build-cross-tools arm ../../buildtools```
+2. Leverage configure to build your ARM toolchain. ```../configure -j2 --cross-tools-source ../../buildtools --build-cross-tools arm```
 
 ## Building an MMC (SD Card) Image
 
 Once you have a complete ARM toolchain, you can build a Haiku MMC disk image via ``jam -j2 -q @minimum-mmc``
-This will generate an MMC image suitable for booting Haiku on a real ARM hardware device.
+This will generate an MMC image suitable for booting Haiku on real ARM hardware devices or in emulators like QEMU
 
-{{< alert-warning "Post-processing" "The generated MMC image only contains Haiku software. Most ARM hardware devices will require extra binary bootloaders (including u-boot). User-run automated post-processing tools are being developed to automate these steps.">}}
+{{< alert-warning "Post-processing" "The generated MMC image only contains Haiku software. Most physical ARM hardware devices will require extra binary bootloaders (including u-boot). Users can leverage the Rune tool to post-process generic Haiku ARM images for their target ARM device.">}}
 
 ## Emulating ARM Image
 
-The ARM images can also be emulated in QEMU. In the example below, we emulate a Raspberry Pi 2.
+The ARM images can also be emulated in QEMU ARM with an EFI bios like Tianocore.
 
-```sh qemu-system-arm -M raspi2 -kernel haiku_loader.ub -initrd haiku-floppyboot.tgz.ub -dtb rpi2.dtb -m 2G```
+> haiku-mmc.image contains our bootloader. haiku-minimum.mmc contains our filesystem. These need to be combined
+> in the future.  You can remove the "-hdb haiku-minimum.mmc" to see our bootloader menu on arm (or theoretically tap space?)
+
+The location of the ARM Tianocore bios will vary based on platform. This example is for Fedora:
+
+```qemu-system-arm -M virt -m 1024 -bios /usr/share/edk2/arm/QEMU_EFI.fd -device virtio-gpu -hda haiku-mmc.image -hdb haiku-minimum.mmc```
+
+> Be sure to examine the uart console in QEMU for debug data from our bootloader / kernel.
+
+## Running on real hardware
+
+{{< alert-warning "Dragons" "While the 'structure' has been setup to get Haiku booting on real hardware, more work needs to be done to make it work reliably.">}}
+
+Generally, you'll need to "post-process" the Haiku MMC image for your target ARM device.
+The [Rune](https://github.com/haiku/rune) tool was designed for this purpose. It will download the necessary binary blobs to get Haiku running and inject them to the MMC image.
+
+### Provisioning an SD card directly
+
+Be sure to replace /dev/sde with your SD card block device.
+
+```rune -b rpi2 -i haiku-mmc.image /dev/sde```
+
+### Creating an SD card image
+
+```rune -b rpi3 -i haiku-mmc.image /home/alex/haiku-rpi3.mmc```
+```dd if=/home/alex/haiku-rpi3.mmc of=/dev/sde```
+
+### Adding support for additional ARM hardware
+
+If upsteam u-boot supports your board, open a ticket to https://github.com/haiku/firmware with the details and help us expand our inventory of supported devices!

content/guides/building/compiling-powerpc.md

@@ -8,7 +8,7 @@ tags = ["PowerPC compiling"]
 <h3>PowerPC Compiler Toolset</h3>
 <p>Building the PowerPC compiler toolset is quite easy and involves generating gcc binaries for your platform. For a complete list of flags for the configure script, see <a href='/guides/building/configure'>Haiku's Configure Options</a></p>
 <p>From the haiku source directory, run the following. (be sure to adjust the options to match your build environment.)
-<pre class="terminal">./configure --build-cross-tools ppc ../buildtools</pre></p>
+<pre class="terminal">./configure --cross-tools-source ../buildtools --build-cross-tools ppc</pre></p>
 
 <p>If you want to run configure again to tweak some more options, you need to tell it to configure for PowerPC. This is done with the --cross-tools-prefix option:
 <pre class="terminal">../configure --use-gcc-pipe --cross-tools-prefix cross-tools/bin/ppc-unknown-haiku-

content/guides/building/compiling-sparc.md

@@ -17,7 +17,7 @@ Building the SPARC compiler toolchain is quite easy using Haiku's ```configure``
 
 1. Perform a git clone haiku and buildtools
 2. Within the haiku source directory, create your workspace for SPARC via ```mkdir generated.sparc; cd generated.sparc```
-2. Run configure to build your SPARC toolchain. ```../configure --use-gcc-pipe -j4 --build-cross-tools sparc ../../buildtools```
+2. Run configure to build your SPARC toolchain. ```../configure --use-gcc-pipe -j4 --cross-tools-source ../../buildtools --build-cross-tools sparc```
 
 ## Building a filesystem image
 

content/guides/building/compiling-x86.md

@@ -33,18 +33,7 @@ binaries for your platform. For a complete list of flags for the configure
 script, see <a href='/guides/building/configure'>Haiku's Configure Options</a>
 
 ```sh
-./configure --build-cross-tools x86_gcc2 ../buildtools --build-cross-tools x86
-```
-
-<h3>Compiling a basic raw Haiku disk image</h3>
-
-<p>This is the most basic build, it generally is good for quickly testing the
-OS after making modifications as it doesn't contain a lot of extra applications.
-Be sure to modify -j2 with the number of cpu cores on your build system to
-ensure the fastest build times.</p>
-
-```sh
-jam -q -j2 @image
+./configure --cross-tools-source ../buildtools --build-cross-tools x86_gcc2 --build-cross-tools x86
 ```
 
 <h3>Compiling raw nightly disk images</h3>
@@ -54,3 +43,11 @@ This is the default nightly image build target. This contains a complete system
 ```sh
 jam -q -j2 @nightly-raw
 ```
+
+<h3>Compiling anyboot nightly disk images</h3>
+
+You can also choose to build an anyboot image (`*.img`) instead, which is generally more useful for virtualization software.
+
+```sh
+jam -q -j2 @nightly-anyboot
+```

content/guides/building/compiling-x86_64.md

@@ -21,12 +21,12 @@ the build tools (be sure to adjust the options to match your build environment):
 **Working in a clean build directory:**
 ```sh
 mkdir generated.x86_64; cd generated.x86_64
-../configure --build-cross-tools x86_64 ../../buildtools
+../configure --cross-tools-source ../../buildtools --build-cross-tools x86_64
 ```
 
 **Working in the top level:**
 ```sh
-./configure --build-cross-tools x86_64 ../buildtools
+./configure --cross-tools-source ../buildtools --build-cross-tools x86_64
 ```
 
 x86_64 Haiku Builds

content/guides/building/configure/_index.html

@@ -8,14 +8,18 @@ tags = []
 As of February 2010, Haiku's `configure` has several interesting options.  These options are briefly explained by running `configure --help` on the command line.  Below, additional information will be discussed as a complement to the usage output text.
 
 <ul>
-<li><h4>--build-cross-tools &lt;arch&gt; &lt;build tools dir&gt;</h4>
-Compile the build tools for one of the following &lt;arch&gt; [x86|x86_gcc2|x86_64|ppc|arm|m68k|mips]. "x86_gcc2" will build gcc2 build tools. Using gcc2 is only a concern if you require binary compatibility with BeOS. All other architectures use gcc7. To build a supported hybrid combination you can repeat the --build-cross-tools for the secondary architecture, but without a &lt;build tools dir&gt;. A note about <a href="#buildtoolsdir">&lt;build tools dir&gt;</a>.
-</li>
+<li><h4>--build-cross-tools &lt;arch&gt;</h4>
+Compile the build tools for one of the following &lt;arch&gt; [x86|x86_gcc2|x86_64|ppc|arm|m68k|mips]. "x86_gcc2" will build gcc2 build tools. Using gcc2 is only a concern if you require binary compatibility with BeOS. All other architectures use gcc7. To build a supported hybrid combination you can repeat the --build-cross-tools for the secondary/additional architectures. Be sure to specify <code>--cross-tools-source</code> when using these flags.
+</li
 
 <li><h4>--cross-tools-prefix &lt;prefix&gt;</h4>
 Point to pre-built binaries of the build tools. This can be used after the cross-tools have been compiled with a previous <code>configure --build-cross-tools ...</code>. The option can be repeated to specify the secondary build tools for a Hybrid.
 </li>
 
+<li><h4>--cross-tools-source &lt;build tools dir&gt;</h4>
+Point to the buildtools (toolchain source code) for Haiku. This only needs specified once when using </code>--build-cross-tools</code>. A note about <a href="#buildtoolsdir">&lt;build tools dir&gt;</a>.
+</li>
+
 <li><h4>--distro-compatibility &lt;level&gt;</h4>
 The distribution's level of compatibility with the official Haiku distribution. The generated files will contain the respective trademarks accordingly. Currently supported values are:
 

content/guides/building/configure/different-generated.md

@@ -24,7 +24,7 @@ tags = []
 
 <pre class="terminal">
 cd /path/haiku/haiku/generated.x86_gcc2/
-../configure --build-cross-tools x86_gcc2 ../../buildtools
+../configure --cross-tools-source ../../buildtools --build-cross-tools x86_gcc2
 jam -q @alpha-raw
 </pre>
 

content/guides/building/gcc-hybrid.md

@@ -63,7 +63,7 @@ Be sure to consult the various <a href="/guides/building/configure">configure op
 
 ```sh
   cd generated.x86gcc2
-  ../configure --build-cross-tools x86_gcc2 ../../buildtools/ --build-cross-tools x86
+  ../configure --cross-tools-source ../../buildtools/ --build-cross-tools x86_gcc2 --build-cross-tools x86
 ```
 
 <h3>Jamming inside one of the generated folders</h3>
@@ -71,11 +71,20 @@ Be sure to consult the various <a href="/guides/building/configure">configure op
 Be sure to consult the various <a href="/guides/building/jam">jam options</a>.
 </div>
 
+In order to build a raw Haiku image, run the following:
+
 ```sh
   cd generated.x86gcc2
   jam -q @nightly-raw
 ```
 
+Alternatively, you may be interested in building an anyboot image instead:
+
+```sh
+  cd generated.x86gcc2
+  jam -q @nightly-anyboot
+```
+
 <p>
 If you have set up multiple generated.* directories, the builds won't affect each other. In each generated.* directory you can only build the exact Haiku configuration it has been configured for.
 </p>

content/guides/building/get-source-git.md

@@ -129,6 +129,12 @@ Note however that these repositories do not contain any hrev tags, which are use
 
 <h3>Common tasks</h3>
 
+If you are already familiar with the pull request workflow as used, for example, at GitHub, you
+can find an overview of the differences in <a href="https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough-github.html">Gerrit user's manual</a>.
+
+<h4>Example git workflow</h4>
+<img src='/files/gitProcess_0.png'>
+
 <h4>Updating the Sources</h4>
 
 <div class="alert alert-danger">
@@ -216,8 +222,94 @@ and push them again, until they are reviewed and merged.
 It is recommended to set a topic, a single keyword that can easily be searched
 for in the web interface and help categorize commits.
 
+<h4>Taking review comments into account and updating a commit</h4>
+
+Usually your changes will not be accepted on the first try. Other developers
+will review it, making sure they understand what you are doing, and maybe
+help you find better ways of doing it. They will also check that your code
+follows the coding guidelines, which are important to make sure the code is
+easy to read and uses the same conventions in all the codebase.
+
+<h5>Single-commit change</h5>
+
+To update an existing commit, you need to download it locally, modify it,
+and send it again. When your change consists of a single commit, you can
+cherry-pick it.
+
+First make sure you start from a clean working tree with the latest Haiku changes
+(note that this will remove all your work in progress commits from the working
+copy, make sure they are in a branch. Git will remind you about this if it's the
+case).
+
+```sh
+git fetch
+git checkout origin/master
+```
+
+Then you can download your commit from Gerrit. To do this, use the Gerrit
+web interface and the Download -&gt; Cherry Pick button, which allows you to
+copy the required git command. It looks like this, but it is different for
+each commit and each version of a commit so make sure to get the correct one
+from Gerrit:
+
+```sh
+git fetch "ssh://user@git.haiku-os.org/haiku" refs/changes/28/3228/4 && git cherry-pick FETCH_HEAD
+```
+
+You can now edit the files to make the needed changes. Once you are done, edit
+the commit to include your changes:
+
+```sh
+git add a/modified/file.cpp another/modified/file.h # you can use wildcards, or just 'git add .' to add everything modified
+git commit --amend # modify the commit
+```
+
+Make sure the commit message contains the change-id for the commit. If it doesn't,
+copy it from Gerrit and add it at the end of the commit message.
+
+Finally, send your work for review:
+
+```sh
+git push origin HEAD:refs/for/master
+```
+
+<h5>Multiple-commit change</h5>
+
+The process is similar when your change is split into multiple commits, but
+you can't as easily use cherry-pick since it would have to be done once per
+commit. So, a different process can be used instead.
+
+First of all make sure you have the latest version of Haiku:
+
+```sh
+git fetch
+```
+
+Then go to the latest commit of your change in progress and use the
+Download -&gt; Checkout menu to get all the changes at once. Again, note that
+the command changes for each commit, so be sure to get the correct one from
+Gerrit. The one below is only an example.
+
+```sh
+git fetch "ssh://user@git.haiku-os.org/haiku" refs/changes/99/1299/5 && git checkout FETCH_HEAD
+```
+
+You can then rebase your changes on the current version of Haiku:
+
+```sh
+git rebase origin/master
+```
+
+You can use git commit --amend to edit the latest commits and add more commits
+to the branch. To modify the previous commits, you need to use git interactive
+rebase (git rebase -i). See <pre>git help rebase</pre> for more help on rebasing.
+
+Once you are done, you can update your patches on Gerrit:
+
+```sh
+git push origin HEAD:refs/for/master
+```
+
 Read the <a href="https://review.haiku-os.org/Documentation/user-upload.html">Gerrit documentation</a> for a more detailed
 overview of the process.
 
-<h4>Example git workflow</h4>
-<img src='/files/gitProcess_0.png'>

content/guides/building/port_status.html

@@ -17,7 +17,7 @@ real-world developer interest.<br/><br/>
 <tr><td>32-bit x86 PC</td><td>High</td><td>x86</td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td>Stable</td></tr>
 <tr><td>64-bit x86 PC</td><td>High</td><td>x86_64</td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td>Production</td></tr>
 
-<tr><td COLSPAN=7><h3>ARM (Tier 2)</h3>Newly revitalized line of processors excelling at low power consumption and low cost. See <a href="https://cgit.haiku-os.org/haiku/tree/docs/develop/ports/arm">platform-specific notes</a> in the source tree.</td></tr>
+<tr><td COLSPAN=7><h3>ARM (Tier 2)</h3>Newly revitalized line of processors excelling at low power consumption and low cost. See <a href="https://git.haiku-os.org/haiku/tree/docs/develop/kernel/arch/arm">platform-specific notes</a> in the source tree.</td></tr>
 <tr><th>Platform</th><th>Interest</th><th>Target</th><th>Haiku Loader</th><th>Haiku Kernel</th><th>Application Server</th><th>Status</th></tr>
 <tr><td><a href="http://beagleboard.org" title="BeagleBoard">BeagleBoard</a> Black</td><td>Moderate</td><td>beagle</td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>20%</td></tr>
 <tr><td><a href="http://www.cubieboard.org/">Cubieboard 4</a></td><td>Moderate</td><td>cubieboard4</td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>10%</td></tr>
@@ -32,14 +32,14 @@ real-world developer interest.<br/><br/>
 <tr><td>Genesi <a href="http://www.genesi-tech.com/products/efika">Efika MX</a></td>
 	<td>Moderate</td><td>???</td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>10%</td></tr>
 
-<tr><td COLSPAN=7><h3>PowerPC (Tier 2)</h3>Previous challenger to the x86 market in desktop and laptop computers. See <a href="https://cgit.haiku-os.org/haiku/tree/docs/develop/ports/ppc">platform-specific notes</a> in the source tree.</td></tr>
+<tr><td COLSPAN=7><h3>PowerPC (Tier 2)</h3>Previous challenger to the x86 market in desktop and laptop computers. See <a href="https://git.haiku-os.org/haiku/tree/docs/develop/kernel/arch/ppc">platform-specific notes</a> in the source tree.</td></tr>
 <tr><th>Platform</th><th>Interest</th><th>Target</th><th>Haiku Loader</th><th>Haiku Kernel</th><th>Application Server</th><th>Status</th></tr>
 <tr><td>Genesi Efika I & II</td><td>Low</td><td>ppc</td><td><img src='/files/status-icons/complete.png' alt='Complete'></td><td><img src='/files/status-icons/need-maintainer.png' alt='Need Maintainer'></td><td><img src='/files/status-icons/need-maintainer.png' alt='Need Maintainer'></td><td>80%</td></tr>
 <tr><td>Apple G3/G4</td><td>Low</td><td>ppc</td><td><img src='/files/status-icons/need-maintainer.png' alt='Need Maintainer'></td><td><img src='/files/status-icons/need-maintainer.png' alt='Need Maintainer'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>10%</td></tr>
 <tr><td>ACube Sam460ex</td><td>High</td><td>ppc</td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>10%</td></tr>
 <tr><td>BeBox</td><td>None</td><td>ppc</td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td><td>0%</td></tr>
 
-<tr><td COLSPAN=7><h3>Sparc (Tier 2)</h3>Open, royalty-free CPU architecture, historically with several manufacturers. Well documented and clean hardware. See <a href="https://cgit.haiku-os.org/haiku/tree/docs/develop/ports/sparc">platform-specific notes</a> in the source tree.</td></tr>
+<tr><td COLSPAN=7><h3>Sparc (Tier 2)</h3>Open, royalty-free CPU architecture, historically with several manufacturers. Well documented and clean hardware. See <a href="https://git.haiku-os.org/haiku/tree/docs/develop/kernel/arch/sparc">platform-specific notes</a> in the source tree.</td></tr>
 <tr><th>Platform</th><th>Interest</th><th>Target</th><th>Haiku Loader</th><th>Haiku Kernel</th><th>Application Server</th><th>Status</th></tr>
 <tr><td>Sun Ultra 60</td><td>Low</td><td>sparc</td>
 	<td><img src='/files/status-icons/in-progress.png' alt='In Progress'></td>
@@ -52,7 +52,7 @@ real-world developer interest.<br/><br/>
 	<td><img src='/files/status-icons/no-work.png' alt='No Work Complete'></td>
 	<td>15%</td></tr>
 
-<tr><td COLSPAN=7><h3>m68k (Tier 3)</h3>Classic home computer devices. See <a href="https://cgit.haiku-os.org/haiku/tree/docs/develop/ports/m68k">platform-specific notes</a> in the source tree.</td></tr>
+<tr><td COLSPAN=7><h3>m68k (Tier 3)</h3>Classic home computer devices. See <a href="https://git.haiku-os.org/haiku/tree/docs/develop/kernel/arch/m68k">platform-specific notes</a> in the source tree.</td></tr>
 <tr><th>Platform</th><th>Interest</th><th>Target</th><th>Haiku Loader</th><th>Haiku Kernel</th><th>Application Server</th><th>Status</th></tr>
 <tr><td>Atari TT</td><td>Low</td><td>m68k</td>
 	<td><img src='/files/status-icons/need-maintainer.png' alt='Need Maintainer'></td>

content/guides/building/pre-reqs.md

@@ -102,7 +102,7 @@ sudo apt-get install u-boot-tools util-linux device-tree-compiler bc
 **Basic requirements:**
 
 ```sh
-sudo pacman -S base-devel bison git texinfo nasm openssh unzip curl wget flex xorriso bc mtools python
+sudo pacman -S base-devel multilib-devel bison git texinfo nasm openssh unzip curl wget flex xorriso bc mtools python lib32-glibc
 ```
 
 **Additional requirements for ARM:**
@@ -150,17 +150,18 @@ sudo emerge -av dev-vcs/git autoconf automake texinfo flex bison gawk tar sys-li
 sudo emerge -av u-boot-tools util-linux dtc bc
 ```
 
-<a name="bsd"></a>
-## ![freebsd](/files/os-icons/freebsd-32.png) BSD Based Distribution (FreeBSD)
+<a name="freebsd"></a>
+## ![freebsd](/files/os-icons/freebsd-32.png) FreeBSD
+
+**Basic requirements:**
 
-**Package based:**
 ```sh
-sudo pkg install bison git nasm gawk texinfo xorriso wget u-boot-tools mtools linuxfdisk curl python3 gcc gmake
+pkg install devel/bison devel/git devel/nasm lang/gawk print/texinfo sysutils/xorriso ftp/curl ftp/wget sysutils/u-boot-tools emulators/mtools sysutils/linuxfdisk lang/python lang/gcc devel/gmake
 ```
 
-**Ports based:**
+The configure script has to be run with extra enviroment variables to tell it the location of gcc-ranlib and gcc-ar, for example:
 ```sh
-sudo portinstall devel/bison devel/git devel/nasm lang/gawk print/texinfo sysutils/xorriso ftp/curl ftp/wget devel/u-boot-tools emulators/mtools sysutils/linuxfdisk lang/python devel/gcc devel/gmake
+$ NM=gcc-nm9 RANLIB=gcc-ranlib9 AR=gcc-ar9 ./configure --cross-tools-source ../buildtools/ --build-cross-tools x86_64
 ```
 
 <a name="osx"></a>

content/guides/virtualizing/virtualbox.md

@@ -9,7 +9,7 @@ For Google Code In 2017, Jakub Pajdowski created a [video on how to install Haik
 
 Virtual instances of operating systems are perfect for all kinds of testing purposes that need to be done in a safe and isolated environment. Installing Haiku in a virtual machine is a solution for people who do not want to install it on their physical computers, but wish to become familiar with it.
 
-This How-To guide will describe the process of running Haiku on virtual machine (VM) using VirtualBox 3.2 There are two ways it can be done– one is installing and running Haiku from CD-ROM image, which is similar to a physical instance. Ror convenience and time-saving purposes, the user may also use the already prepared VM hard disk image. The decision is left up to the user, although many people prefer VM image as it is easier to manage.
+This How-To guide will describe the process of running Haiku on virtual machine (VM) using VirtualBox 3.2 There are two ways it can be done– one is installing and running Haiku from CD-ROM image, which is similar to a physical instance. For convenience and time-saving purposes, the user may also use the already prepared VM hard disk image. The decision is left up to the user, although many people prefer VM image as it is easier to manage.
 
 For this tutorial we will be using an ISO image file - it can be obtained [here](/get-haiku). The VirtualBox virtualization software and installation manual can be downloaded from [here](http://www.virtualbox.org/wiki/Downloads).
 
@@ -40,7 +40,7 @@ The next step is to define how much of the host’s physical memory we want to a
 
 ![](/files/guides/virtualizing/virtualbox/vbox_3.png)
 
-After we have done that, we need to create a hard disk image, which is going to be stored on the physical drive, at the specified location. We choose *Create a virtual harddrive now* (if it is not selected already) and click **`Create`**:
+After we have done that, we need to create a hard disk image, which is going to be stored on the physical drive, at the specified location. We choose *Create a virtual hard disk now* (if it is not selected already) and click **`Create`**:
 
 ![](/files/guides/virtualizing/virtualbox/vbox_4.png)
 
@@ -78,7 +78,7 @@ Hopefully, at this point everything is properly configured and we can run the Ha
 
 The installation itself is quite simple and does not differ really from a physical one (follow the guides [on this page](/get-haiku/installation-guide) if you are not familiar with installing Haiku).
 
-DriveSetup should detect two devices, one is our CD-ROM (ISO) file and another is the “harddrive” we created earlier. All we need to do is select that drive, go to *Partitions -> Format*, click on *Be File System* and continue the initialization. Then you use Installer from the Deskbar's appliction menu to install from the CD image to the big virtual harddrive.
+DriveSetup should detect two devices, one is our CD-ROM (ISO) file and another is the “hard disk” we created earlier. All we need to do is select that drive, go to *Partitions -> Format*, click on *Be File System* and continue the initialization. Then you use Installer from the Deskbar's application menu to install from the CD image to the big virtual hard disk.
 
 ![](/files/guides/virtualizing/virtualbox/image11.png)
 
@@ -119,7 +119,7 @@ First solution is simply adjusting the screen resolution using tools built into
 ![](/files/guides/virtualizing/virtualbox/image17.png)
 
 <a name="part_customVESA"></a>
-The other way is to resize the guest window through the host. While Virtual Guest Additions are available from HaikuDepot, there is no automatic window resizing support yet. However the user may use custom VESA resoultion as a workaround.
+The other way is to resize the guest window through the host. While Virtual Guest Additions are available from HaikuDepot, there is no automatic window resizing support yet. However the user may use custom VESA resolution as a workaround.
 
 For example, type this in your host system:
 ```sh

content/news/2020-09-11-system-sound-contest.md

@@ -0,0 +1,93 @@
++++
+type = "news"
+title = "Contest for System Sounds"
+author = "bitigchi"
+date = "2020-09-06 13:00:00+03:00"
+tags = ["sound", "contest"]
++++
+
+**UPDATE (2020/12/08):** The contest has concluded. See [this blog post](/news/2020-12-07-contest-results.md) for the results.
+
+It wouldn't be wrong to say that, Haiku is a unique operating system. It takes its roots from BeOS, the OS everyone envied back in the day. Haiku continues to follow its footsteps, trying to deliver that same experience. What could be better than complementing this unique operating system with a set of unique system sounds?
+
+As R1 steadily approaches, we are looking for contestants (amateur, professional, enthusiast) to produce system sound effects for Haiku. Specifically sounds for:
+
+**General:**
+
+- Beep
+- A nice and soothing startup chime
+
+**Notifications:**
+
+- Information notification
+- Important notification
+- Error notification
+- Progress notification (= the percentage of the progress bar gets updated)
+
+**Key/mouse events:**
+
+- Key down
+- Key repeat
+- Key up
+- Keymap switch
+- Mouse down
+- Mouse up
+
+**Window events:**
+
+- Window activated (= gets focus)
+- Window close
+- Window minimised (= window tab gets double-clicked to hide the window)
+- Window open
+- Window restored (= gets 'unminimised')
+- Window zoomed (= when 'zoom' button (right widget in tab) is clicked)
+
+## Contest guidelines
+
+- All sound effects except the startup chime should be up to 1 second long. If the situation calls for, it can be longer, but it **should** not exceed 2 seconds. For startup chime, the limit is 5 seconds.
+- All sound effects should be non-intrusive. Distorted tunes, high-pitched tunes will not be considered.
+- Expanding on "haiku" and related themes are encouraged.
+- Entries need to be in uncompressed PCM format.
+- Entries should include a note that the work is licensed under [CC Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/) or a similar license. The license file should look something like this:
+```
+    Haiku System Sounds   
+    [Name-of-the-sound-theme]    
+    Copyright 2020, [Name-of-the-artist] <emailaddress@something.net>   
+    Licensed under CC Attribution-ShareAlike 4.0 International.   
+    [Optional additional info]
+```
+- Naming the sound files according to the theme is encouraged, but intended sound event should be noted appropriately.
+
+## Submission deadline
+
+Deadline for the contest is November 25th, 2020; we would like to have the new default sound theme ready in time around Haiku Beta3. We also plan to package and release qualifying submissions as separate packages available for download on the main Haiku software repository.
+
+## How to participate
+
+Send an e-mail to humdingerb (gmail) com and bitigchi (me) com with a link to your zipped up work. Entries and news regarding the contest will be added to this post.
+
+The winner will be decided by a poll in [Haiku forums](https://discuss.haiku-os.org) starting December 1st, 2020, and will be announced on the website and the [Haiku general mailing list](https://www.freelists.org/list/haiku) on December 7th, 2020.
+
+Thanks for being a part of the Haiku universe!
+
+## Contest Entries (In-progress)
+
+- bearlyMatt - Komorebi ([Download link](/files/sound-contest/bearlyMatt-Komorebi.zip) [3.1 MiB] - added 2020/11/25)
+- Benjamin Davis ([Download link](/files/sound-contest/benjamin_davis_Forest_Dreams.zip) [3.3 MiB] - added 2020/11/07)
+- Dahuyn Lee - Meditation Time ([Download link](/files/sound-contest/dahuyn_lee_Meditation_Time.zip) [4 MiB] - added 2020/11/19)
+- Daniel Diaz ([Download link](/files/sound-contest/daniel_diaz.zip) [4.4 MiB] - added 2020/10/03)
+- Denis Čumak - Clack ([Download link](/files/sound-contest/denis_cumak_Clack.zip) [5.8 MiB] - added 2020/11/10)
+- Garrett Kabler - burg's-sparkly-tones ([Download link](/files/sound-contest/garrett_kabler_burgs-sparkly-tones.zip) [1.8 MiB] - updated 2020/11/24)
+- Humdinger - Low Modulorian ([Download link](/files/sound-contest/humdinger_Low_Modulorian.zip) [2.9 MiB] - updated 2020/10/13)
+- Jason Richardson - Bassling ([Download link](/files/sound-contest/jason_richardson.zip) [3.6 MiB] - added 2020/10/04)
+- Joshua Spann - Zen ([Download link](/files/sound-contest/joshua_spann.zip) [1.6 MiB] - updated 2020/10/13)
+- Luke Stegmayer - Nature ([Download link](/files/sound-contest/luke_stegmayer_Nature.zip) [2 MiB] - updated 2020/11/26)
+- Maksim Malerson - Basics ([Download link](/files/sound-contest/maksim_malerson_Basics.zip) [723 KiB] - updated 2020/11/19)
+- Nomys Tempar - The Poet Operating System Theme ([Download link](/files/sound-contest/nomys_tempar.zip) [2.8 MiB] - added 2020/11/17)
+- Olivier Coursière - Supposedly Not Too Annoying Theme ([Download Link](/files/sound-contest/olivier-coursiere-supposedly-not-too-annoying-theme.zip) [4.9 MiB] - added 2020/11/25)
+- Parnikkapore - Yanqim ([Download link](/files/sound-contest/parnikkapore-yanqim.zip) [2.2 MiB] - updated 2020/11/25)
+- Gareth White - Straight Outta Cronton ([Download link](/files/sound-contest/gareth_white_straight_outta_cronton.zip) [3.4 MiB] - added 2020/10/10)
+- Tim Lyakhovetskiy - Leafy ([Download link](/files/sound-contest/tim_lyakhovetskiy_leafy.zip) [2.6 MiB] - added 2020/10/17)
+- Ward Bones - Zen Peace ([Download link](/files/sound-contest/ward_bones_Zen_Peace.zip) [3.2 MiB] - added 2020/11/19)
+
+You can download all entries in one [tar.gz archive](https://oshi.at/ATySSh) [52 MiB]. Unpack with Expander.