https://wiki.restless.systems/api.php?action=feedcontributions&feedformat=atom&user=KraaabsDisNCord Community Wiki - User contributions [en]2026-05-29T17:30:36ZUser contributionsMediaWiki 1.42.1https://wiki.restless.systems/index.php?title=Building_OpenFirmware_for_QEMU&diff=1167Building OpenFirmware for QEMU2023-02-23T22:40:58Z<p>Kraaabs: add gitlab link to the dockerfile ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
In 2006, the source code for OpenFirmware<ref>https://openfirmware.info/Welcome_to_OpenBIOS</ref> on x86 was released. Although there are instructions<ref>https://openfirmware.info/Open_Firmware#Building_Different_Versions</ref> for building images for use with QEMU, they are sparse and don't work any more on modern, 64-bit Linux.<br />
<br />
== Setting up your own build environment ==<br />
As far as I can tell, building OpenFirmware requires an older version of GCC as well as multilib support. The easiest way to get both of these things at once is to use an older Linux distribution in a virtual machine.<br />
<br />
Slackware 14.2 (the 32-bit version) is known to produce working builds. Just install the entire distribution and follow the [https://openfirmware.info/Open_Firmware#Building_Different_Versions instructions on the OpenFirmware wiki] to build your image of choice. As of 2023/02/22, this method seems to work fine.<br />
<br />
As well, [[User:Kraaabs]] has created a Dockerfile to build images without having to set up your own VM: [https://gitlab.com/sarahcrowle/of-docker-build https://gitlab.com/sarahcrowle/of-docker-build]<br />
<br />
== So why doesn't it work? ==<br />
OpenFirmware is actually bootstrapped using a FORTH interpreter that it builds before the "real" build process starts. This interpreter is ''known'' not to build on aarch64, and segfaults on x86_64. 32-bit builds of the interpreter ''appear'' to work, but they produce broken images (with no error message!).<br />
<br />
At this point it's unclear whether the issue is with the FORTH interpreter itself (likely) or with the FORTH code used to build OpenFirmware (less likely). Either way, building on an older 32-bit system seems to work just fine, and produces images that run in modern versions of QEMU.<br />
<br />
== Just give me images! ==<br />
[[User:Kraaabs]] has successfully built every kind of QEMU OpenFirmware image for x86. [https://picsofbread.com/dl/ofw-images.tar.xz Download here.]<br />
<br />
== Footnotes/references ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Building_OpenFirmware_for_QEMU&diff=1165Building OpenFirmware for QEMU2023-02-23T02:53:18Z<p>Kraaabs: a little page about building openfirmware in 2023 ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
In 2006, the source code for OpenFirmware<ref>https://openfirmware.info/Welcome_to_OpenBIOS</ref> on x86 was released. Although there are instructions<ref>https://openfirmware.info/Open_Firmware#Building_Different_Versions</ref> for building images for use with QEMU, they are sparse and don't work any more on modern, 64-bit Linux.<br />
<br />
== Setting up your own build environment ==<br />
As far as I can tell, building OpenFirmware requires an older version of GCC as well as multilib support. The easiest way to get both of these things at once is to use an older Linux distribution in a virtual machine.<br />
<br />
Slackware 14.2 (the 32-bit version) is known to produce working builds. Just install the entire distribution and follow the [https://openfirmware.info/Open_Firmware#Building_Different_Versions instructions on the OpenFirmware wiki] to build your image of choice. As of 2023/02/22, this method seems to work fine.<br />
<br />
== So why doesn't it work? ==<br />
OpenFirmware is actually bootstrapped using a FORTH interpreter that it builds before the "real" build process starts. This interpreter is ''known'' not to build on aarch64, and segfaults on x86_64. 32-bit builds of the interpreter ''appear'' to work, but they produce broken images (with no error message!).<br />
<br />
At this point it's unclear whether the issue is with the FORTH interpreter itself (likely) or with the FORTH code used to build OpenFirmware (less likely). Either way, building on an older 32-bit system seems to work just fine, and produces images that run in modern versions of QEMU.<br />
<br />
== Just give me images! ==<br />
[[User:Kraaabs]] has successfully built every kind of QEMU OpenFirmware image for x86. [https://picsofbread.com/dl/ofw-images.tar.xz Download here.]<br />
<br />
== Footnotes/references ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=EAWebKit&diff=976EAWebKit2023-01-29T22:34:12Z<p>Kraaabs: /* Building EAWebKit */</p>
<hr />
<div>[[Category:Projects]]<br />
[[Category:Preservation and Documentation]]<br />
EAWebKit is EA's WebKit fork for use in their games and software. It's technically open source as per LGPL requirements<ref>https://gpl.ea.com/eawebkit.html</ref>, but getting it to build is another story...<br />
<br />
[[User:Kraaabs]] is currently trying to get a build of EAWebKit working.<br />
<br />
== Building EAWebKit ==<br />
EAWebKit does away with the CMake build system of regular WebKit (see [[Notes on WebKit]]) in favour of a set of hacked up Visual Studio solutions and projects. Therefore, at the moment we're only trying to build for Windows (however, other platforms should still be supported).<br />
<br />
Unfortunately, the versions of EASTL<ref>https://github.com/electronicarts/EASTL</ref> and EABase<ref>https://github.com/electronicarts/EABase</ref> (support libraries) bundled with the GPL source release of EAWebKit 16.4.2.0.0 are either broken or misconfigured, and they will not build correctly in Visual Studio 2022. Things that are broken are:<br />
<br />
* MSVC floating point intrinsics (such as <code>_Nan</code> etc.)<br />
** This can be resolved by defining <code>EASTL_CUSTOM_FLOAT_CONSTANTS_REQUIRED 1</code> in order to force EASTL to use EA's own implementations of these definitions<br />
* Include paths... Like all of the include paths.<br />
** No resolution yet... this will probably require manual fixing of every single vcxproj in the build system.<br />
* Some source paths are wrong in the vcxproj files<br />
** An example is <code>EAWebKitSupportPackages\JavaScriptCore\local\JavaScriptCore\DerivedSources\pc64\dev-debug\LowLevelInterpreterWin.asm</code> in the JavaScriptCore vcxproj. This can be worked around by replacing that source path with an absolute path (is the working directory wrong?)<br />
<br />
=== What about other releases of EAWebKit? ===<br />
Those are even more broken! Releases of EAWebKit before 16.4.2.0.0 are full of hardcoded paths in the project files that break the build completely unless you manually tweak all of them. Luckily, the least broken version seems to be the latest one anyway.<br />
<br />
== See also ==<br />
[[Notes on WebKit]]<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=975Notes on WebKit2023-01-29T22:32:51Z<p>Kraaabs: add backlinks to the eawebkit page ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
* If decoupling EGL is not feasible, and we DO have to write our own backend, [[EAWebKit]] (see below) may be a good reference point (it uses a Cairo based renderer, etc).<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - [[EAWebKit]] is used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.nintendo.co.jp/support/oss/index.html Nintendo WebKit (NetFront NX)] - A variant of Access Co. Ltd.'s WebKit platform NetFront NX, as used on the Wii U, Switch, and 3DS. '''(update: doesn't actually contain any 3DS/Wii U/Switch modifications...?)'''<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. This appears to be false (at least for the PS3 and Vita variants). These variants contain ''Sony'' copyrights, not ''Access'' copyrights like the other NetFront NX-based stuff. (Not that that makes much difference. See below.)<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
=== What makes NetFront NX different from regular WebKit? ===<br />
<br />
Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".<br />
<br />
== See also ==<br />
[[EAWebKit]]<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=EAWebKit&diff=974EAWebKit2023-01-29T22:31:32Z<p>Kraaabs: create initial eawebkit page (for build instructions/patching and stuff... we'll need it) ~Sarah</p>
<hr />
<div>[[Category:Projects]]<br />
[[Category:Preservation and Documentation]]<br />
EAWebKit is EA's WebKit fork for use in their games and software. It's technically open source as per LGPL requirements<ref>https://gpl.ea.com/eawebkit.html</ref>, but getting it to build is another story...<br />
<br />
[[User:Kraaabs]] is currently trying to get a build of EAWebKit working.<br />
<br />
== Building EAWebKit ==<br />
EAWebKit does away with the CMake build system of regular WebKit (see [[Notes on WebKit]]) in favour of a set of hacked up Visual Studio solutions and projects. Therefore, at the moment we're only trying to build for Windows (however, other platforms should still be supported).<br />
<br />
Unfortunately, the versions of EASTL and EABase (support libraries) bundled with the GPL source release of EAWebKit 16.4.2.0.0 are either broken or misconfigured, and they will not build correctly in Visual Studio 2022. Things that are broken are:<br />
<br />
* MSVC floating point intrinsics (such as <code>_Nan</code> etc.)<br />
** This can be resolved by defining <code>EASTL_CUSTOM_FLOAT_CONSTANTS_REQUIRED 1</code> in order to force EASTL to use EA's own implementations of these definitions<br />
* Include paths... Like all of the include paths.<br />
** No resolution yet... this will probably require manual fixing of every single vcxproj in the build system.<br />
* Some source paths are wrong in the vcxproj files<br />
** An example is <code>EAWebKitSupportPackages\JavaScriptCore\local\JavaScriptCore\DerivedSources\pc64\dev-debug\LowLevelInterpreterWin.asm</code> in the JavaScriptCore vcxproj. This can be worked around by replacing that source path with an absolute path (is the working directory wrong?)<br />
<br />
=== What about other releases of EAWebKit? ===<br />
Those are even more broken! Releases of EAWebKit before 16.4.2.0.0 are full of hardcoded paths in the project files that break the build completely unless you manually tweak all of them. Luckily, the least broken version seems to be the latest one anyway.<br />
<br />
== See also ==<br />
[[Notes on WebKit]]<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=948Notes on WebKit2023-01-26T03:56:06Z<p>Kraaabs: /* Other interesting WebKit platforms */</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
* If decoupling EGL is not feasible, and we DO have to write our own backend, EA WebKit (see below) may be a good reference point (it uses a Cairo based renderer, etc).<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - As used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.nintendo.co.jp/support/oss/index.html Nintendo WebKit (NetFront NX)] - A variant of Access Co. Ltd.'s WebKit platform NetFront NX, as used on the Wii U, Switch, and 3DS. '''(update: doesn't actually contain any 3DS/Wii U/Switch modifications...?)'''<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. This appears to be false (at least for the PS3 and Vita variants). These variants contain ''Sony'' copyrights, not ''Access'' copyrights like the other NetFront NX-based stuff. (Not that that makes much difference. See below.)<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
=== What makes NetFront NX different from regular WebKit? ===<br />
<br />
Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=947Notes on WebKit2023-01-26T03:54:29Z<p>Kraaabs: /* Where are we right now? */</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
* If decoupling EGL is not feasible, and we DO have to write our own backend, EA WebKit (see below) may be a good reference point (it uses a Cairo based renderer, etc).<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - As used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.3dbrew.org/w/index.php?title=Internet_Browser 3DS WebKit (NetFront)] - A variant of Access Co. Ltd.'s WebKit platform NetFront. '''(update: doesn't actually contain any 3DS modifications...?)'''<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. This appears to be false (at least for the PS3 and Vita variants). These variants contain ''Sony'' copyrights, not ''Access'' copyrights like the other NetFront NX-based stuff. (Not that that makes much difference. See below.)<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
=== What makes NetFront NX different from regular WebKit? ===<br />
<br />
Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=946Notes on WebKit2023-01-26T03:50:46Z<p>Kraaabs: Sony WebKit is NOT NetFront NX ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - As used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.3dbrew.org/w/index.php?title=Internet_Browser 3DS WebKit (NetFront)] - A variant of Access Co. Ltd.'s WebKit platform NetFront. '''(update: doesn't actually contain any 3DS modifications...?)'''<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. This appears to be false (at least for the PS3 and Vita variants). These variants contain ''Sony'' copyrights, not ''Access'' copyrights like the other NetFront NX-based stuff. (Not that that makes much difference. See below.)<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
=== What makes NetFront NX different from regular WebKit? ===<br />
<br />
Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=945Notes on WebKit2023-01-26T03:49:04Z<p>Kraaabs: </p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - As used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.3dbrew.org/w/index.php?title=Internet_Browser 3DS WebKit (NetFront)] - A variant of Access Co. Ltd.'s WebKit platform NetFront. '''(update: doesn't actually contain any 3DS modifications...?)'''<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. However, contributions to the mainline WebKit tree have some Sony copyrights attached. Further investigation is needed to determine which is which.<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
=== What makes NetFront NX different from regular WebKit? ===<br />
<br />
Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=943Notes on WebKit2023-01-26T02:49:22Z<p>Kraaabs: Add section for existing third-party out-of-tree WebKit platforms (commercial stuff) ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
<br />
== Other interesting WebKit platforms ==<br />
<br />
[[User:Vmlemon]] has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:<br />
<br />
* [https://gpl.ea.com/eawebkit.html EA WebKit] - As used in various EA games for embedded UIs/login screens/what have you. A ''very'' clean Cairo-based backend, and a very small codebase. Could be a great resource.<br />
* [https://doc.dl.playstation.net/doc/ps3-oss/webkit.html PS3 WebKit] - As used in the PS3 web browser.<br />
* [https://github.com/blackberry/WebKit-Smartphone Blackberry WebKit] - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...<br />
* [https://www.3dbrew.org/w/index.php?title=Internet_Browser 3DS WebKit (NetFront)] - A variant of Access Co. Ltd.'s WebKit platform NetFront.<br />
* [https://doc.dl.playstation.net/doc/psvita-oss/webkit.html PS Vita WebKit] - Another Sony WebKit variant, for the PlayStation Vita.<br />
* [https://archive.org/details/web-core-08w-11-prod-08w-37 Nokia S40 WebKit] - As used in the browser for Nokia S40 phones. Previously lost, was recovered by [[User:Vmlemon|vmlemon]] from an old hard drive.<br />
<br />
The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. However, contributions to the mainline WebKit tree have some Sony copyrights attached. Further investigation is needed to determine which is which.<br />
<br />
'''NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!'''<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Permissions&diff=942Project:Permissions2023-01-26T02:35:49Z<p>Kraaabs: </p>
<hr />
<div>This article is dedicated to helping new users understand how to set up a user account and how the different permissions work in this wiki. <br />
<br />
== Setting up a new user account ==<br />
Currently, this wiki requires users to create or login to their account to create or edit pages, which is why most users would want to make an account here.<br />
<br />
=== Creating the account ===<br />
# Go to the underlined text that says "Create account" or the text that says "Log in".<br />
# If you clicked "Create account", simply fill out the required boxes with the relevant information, and fill out the optional boxes if you wish. If you clicked "Log in", click "Join DisNCord community wiki" and then fill out the steps above. <br />
# After this, fill out the bot protection at the bottom, and click "Create account".<br />
<br />
You now have an account, and should automatically be logged into it.<br />
<br />
=== Verifying your email address ===<br />
Note: You only need to do this step if you have specified an email when you were creating your account.<br />
<br />
# Check the inbox of the email address you specififed.<br />
# You should have an email from 'noreply@restless.systems' asking if it was you who added your email to the account you made.<br />
# Click the first link on the page, as it will tell the server that it was you who added your email to that account.<br />
<br />
Your account should now be fully activated and ready for use.<br />
<br />
== User permissions ==<br />
<br />
There are several different "groups" that are in this server that give you various permissions in the wiki.<br />
<br />
'''Administrators''':<br />
These are users which are in charge of moderation and general upkeep of the wiki. Some bots are also in this group as they need admin features to do their task(s).<br />
<br />
'''Bots''':<br />
These are robots that are designed for automatic monitoring of the wiki, among other things. Currently, there are only 2 bots: 'Abuse filter' and '⧼abusefilter-blocker⧽'.<br />
<br />
'''Bureaucrats''':<br />
These are users that can set permissions for other users. Administrators will usually have this.<br />
<br />
'''Check user''':<br />
These users have the ability to see the IP logs on the wiki. <br />
<br />
'''Interface administrator''':<br />
Interface administrators can change the CSS and JS of the wiki. These users are considered administrators. <br />
<br />
'''Suppressors''':<br />
These users have the ability to hide or delete unwanted log entries.<br />
<br />
'''uploadaccess''':<br />
These are users which have the ability to upload images to this wiki using [[Special:Upload|this link]]. You can request this permission by opening a ticket on Discord.<br />
<br />
You can find a list of users that have a specified group [[Special:ListUsers|here]].</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=939Notes on WebKit2023-01-25T20:37:41Z<p>Kraaabs: </p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Notes_on_WebKit&diff=938Notes on WebKit2023-01-25T20:34:45Z<p>Kraaabs: Initial WebKit page ~Sarah</p>
<hr />
<div>[[Category:Preservation and Documentation]]<br />
[[Category:Projects]]<br />
<br />
WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable<ref>https://blogs.igalia.com/jaragunde/files/2015/10/igalia_building_browser_automotive.pdf</ref><ref>https://eu.access-company.com/netfront-html5-platforms-for-automotive.html</ref>, powering platforms such as automotive displays, game consoles, and more.<br />
<br />
Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed [https://github.com/dhamaniasad/HeadlessBrowsers here]) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.<br />
<br />
Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...<br />
<br />
== Architecture ==<br />
<br />
WebKit is actually not the browser engine itself<ref>https://trac.webkit.org/wiki/SourceDirectory</ref>. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.<br />
<br />
As a note, there are actually two WebKit APIs. WebKit2<ref>https://trac.webkit.org/wiki/WebKit2</ref> (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit"<ref>Yes. This will cause confusion.</ref> is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.<br />
<br />
Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.<br />
<br />
=== Where does WPE factor in? ===<br />
<br />
Igalia<ref>https://www.igalia.com/</ref> is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.<br />
<br />
WPE can be considered a "meta" or "hybrid"<ref>https://wpewebkit.org/about/architecture.html</ref> platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.<br />
<br />
WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).<br />
<br />
== How do we add a new platform? ==<br />
<br />
With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration <code>#define</code>s are needed in order to get the platform working. There is some limited documentation<ref>https://trac.webkit.org/wiki/SuccessfulPortHowTo</ref> on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done. <br />
<br />
JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.<br />
<br />
== Where are we right now? ==<br />
<br />
At the moment, [[User:Kraaabs]] has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog<ref>https://github.com/Igalia/cog</ref>, the "reference" WPE frontend. Next steps are:<br />
<br />
* Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?<br />
* Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo<ref>https://www.cairographics.org/</ref> renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.<br />
<br />
== Notes and References ==</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedrunning&diff=912Slow Computing Speedrunning2023-01-24T22:51:40Z<p>Kraaabs: /* Windows 98/ME on the Cursed 486 (NCommander) */</p>
<hr />
<div>[[Category:Competition]]<br />
Welcome to the Slow Computing any% Speedrunning Contest; also known as watching digital paint dry.<br />
<br />
The goal of this contest is simple. To celebrate the long code [https://xkcd.com/303/] times, we're running an informal contest to celebrate this era of batch processing.<br />
<br />
== Objective and Rules ==<br />
<br />
It's pretty simple:<br />
* Using any vintage computer of your choice, perform a long-running task of some sort<br />
* Livestream, or otherwise provide regular status updates that show how far you have gotten.<br />
* Emulators and the like are A-OK; just let us know what it's doing.<br />
<br />
After each run, success or failure, our judges (which is mostly just the regulars in #paint-drying on [https://discord.gg/V8esNah Discord]) will deem what, if any titles such run has earned, and an entirely subjective place on the Wall of Pain. There are absolutely no prizes besides the knowledge that you might be immortalized here for the life of the wiki.<br />
<br />
Do you dare step up?<br />
<br />
=== Examples of projects ===<br />
For example, upgrading through every version of OS/2, building GCC, or the like. Livestream or otherwise regularly update the panting drying competition community. For NCommander's entries, VoDs on YouTube were provided. Europa livestreamed the terminal on Discord throughout the duration. Any sorta long running log with regular updates is acceptable.<br />
<br />
= The Wall of Pain =<br />
New categories will be added as needed<br />
<br />
== Idle Pain ==<br />
Idle Pain refers to tasks where they're started, and mostly left untouched until they finish (excluding minor tweaks, build failures, etc.)<br />
<br />
=== GCC 8 on an Ultra 5 running OpenBSD/sparc64 (Europa) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' Approximately 5.375 days (4.5 days GCC, 0.875 days CDE)<br />
* '''Proof:''' Livestreamed on Discord, updates periodically provided via Discord, [https://twitter.com/europa6502/status/1587304622749876224 Twitter], and Mastodon<br />
* '''Comments:'''<br />
** The build that started it all, Europa's attempt to install CDE which required upgrading GCC, and starting a multiday build process that lead to the creation of the paint drying community ... I'm still wondering how we got here - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
** It finished! She managed to build CDE with her new GCC after some help from NCommander, and is now working on configuring her newly built CDE! - [[User:Kraaabs|Kraaabs]] (([[User talk:Kraaabs|talk]]) 01:56, 7 November 2022 (UTC)<br />
<br />
=== Forcing Windows 7 onto a 66MHz CPU (Griffin) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' About 14 hours<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** The first entry to finish, I believe! They used 86box emulating a VIA Samuel, and a lot of trial and error to get the thing to boot at all. Was a fun one to watch. Nice and painful. [https://twitter.com/FOSSfirefighter/status/1588999569593208832 N tweeted about this one, too.] - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:02, 7 November 2022 (UTC)<br />
<br />
=== Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' <del>Ongoing</del> Failed :(<br />
* '''Duration:''' About 52 hours so far.<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** Yep, still going. It's been about 52 hours (~24-ish of which was prep work), and we're still decompressing the kernel on the Gentoo install CD. In for the long haul, this one. Being that I have to babysit this, is it active pain? There's a lot of waiting. Hybrid pain, maybe. :^) - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:06, 7 November 2022 (UTC)<br />
** It failed a while ago, I'm just lazy. Eventually it hit a timeout :'(. Oh well, it was fun. - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 22:46, 24 January 2023 (UTC)<br />
<br />
=== Compiling every major release of NetBSD on a SparcStation 2 (Daghdha) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 54 days (as of 2 Jan 2023)<br />
* '''Expected to Complete:''' 15 March 2023 (~73 days)<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread. Each release takes a week to build.<br />
<br />
=== Installing Windows 98 inside of Windows XP inside of Windows Vista inside of Windows 8 inside of Windows 10 (Autumn) ===<br />
<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 13 days (as of 1/12/23)<br />
* '''Proof:''' Discord live stream + milestones in the corresponding channel<br />
* '''Comments:''' <br />
** FFS the XP installer took 11 straight days to boot '''''TEXT MODE'''''... I am going to be in for a long wait on this one... - [[User:Autumnbreeze|Autumn]] ([[User talk:Autumnbreeze|talk]]) 12:13, 12 January 2023 (UTC)<br />
<br />
=== Compiling Rust on a Mac OS X 10.7 VM (Bridget) ===<br />
<br />
* '''Status''': Ongoing<br />
* '''Duration''': 3 hours (as of 2022-01-24 02:37 PM)<br />
* '''Proof''': Discord live stream + occasional milestones<br />
* '''Comments''':<br />
** Crap, I didn't tell Macports to download the source versions of the packages. :/ Still took an hour to install the binaries, so we're in for a wild ride here, huh? :P As of writing, it's installing the <code>ncurses</code> dependency. - [[User:Bridgetr|Bridget]] ([[User talk:Bridgetr|talk]]) 14:32, 24 January 2023 (UTC)<br />
<br />
== Active Pain ==<br />
Active Pain entries are livestreams or single projects that are actively worked on over the period of the competition. They can be over multiple sessions, with time being tallied up.<br />
<br />
=== Windows 98/ME on the Cursed 486 (NCommander) ===<br />
* '''Status:''' On Hiatus/Ongoing<br />
* '''Proof:''' https://www.youtube.com/watch?v=0uaINJAktLA (and messages in #content + Fedi)<br />
* '''Duration:''' Multiple attempts over multiple days, one 9 hour<br />
* '''Comments:'''<br />
** You can't install ME on 32 MiB of memory. Upgrades ordered. So far, Windows 98 First Edition was installed from floppies, second edition from Netware, and ME from NetWare and local install, with each attempt taking literal hours. - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 13:44, 2 January 2023 (UTC)<br />
<br />
=== Upgrading Through Every Version of OS/2 (NCommander) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' VoDs: https://www.youtube.com/watch?v=xeaRlhz96mI and https://www.youtube.com/watch?v=8uwGTHZzzF4<br />
* '''Duration:''' Approximately 22 Hours<br />
* '''Comments:''' <br />
** ow [[User:NCommander|- NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
<br />
=== Windows 10 in QEMU on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' Was live-updated on Discord, and also in the [https://picsofbread.com/potato-bread writeup here]<br />
* '''Duration:''' About 10 active hours, and about 18 more waiting for it to boot<br />
* '''Comments:''' <br />
** This was painful. Good way to spend a few days with COVID though. [[User:Kraaabs|- Kraaabs]] ([[User talk:Kraaabs|talk]]) 02:00, 7 November 2022 (UTC)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedrunning&diff=911Slow Computing Speedrunning2023-01-24T22:51:09Z<p>Kraaabs: oops</p>
<hr />
<div>[[Category:Competition]]<br />
Welcome to the Slow Computing any% Speedrunning Contest; also known as watching digital paint dry.<br />
<br />
The goal of this contest is simple. To celebrate the long code [https://xkcd.com/303/] times, we're running an informal contest to celebrate this era of batch processing.<br />
<br />
== Objective and Rules ==<br />
<br />
It's pretty simple:<br />
* Using any vintage computer of your choice, perform a long-running task of some sort<br />
* Livestream, or otherwise provide regular status updates that show how far you have gotten.<br />
* Emulators and the like are A-OK; just let us know what it's doing.<br />
<br />
After each run, success or failure, our judges (which is mostly just the regulars in #paint-drying on [https://discord.gg/V8esNah Discord]) will deem what, if any titles such run has earned, and an entirely subjective place on the Wall of Pain. There are absolutely no prizes besides the knowledge that you might be immortalized here for the life of the wiki.<br />
<br />
Do you dare step up?<br />
<br />
=== Examples of projects ===<br />
For example, upgrading through every version of OS/2, building GCC, or the like. Livestream or otherwise regularly update the panting drying competition community. For NCommander's entries, VoDs on YouTube were provided. Europa livestreamed the terminal on Discord throughout the duration. Any sorta long running log with regular updates is acceptable.<br />
<br />
= The Wall of Pain =<br />
New categories will be added as needed<br />
<br />
== Idle Pain ==<br />
Idle Pain refers to tasks where they're started, and mostly left untouched until they finish (excluding minor tweaks, build failures, etc.)<br />
<br />
=== GCC 8 on an Ultra 5 running OpenBSD/sparc64 (Europa) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' Approximately 5.375 days (4.5 days GCC, 0.875 days CDE)<br />
* '''Proof:''' Livestreamed on Discord, updates periodically provided via Discord, [https://twitter.com/europa6502/status/1587304622749876224 Twitter], and Mastodon<br />
* '''Comments:'''<br />
** The build that started it all, Europa's attempt to install CDE which required upgrading GCC, and starting a multiday build process that lead to the creation of the paint drying community ... I'm still wondering how we got here - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
** It finished! She managed to build CDE with her new GCC after some help from NCommander, and is now working on configuring her newly built CDE! - [[User:Kraaabs|Kraaabs]] (([[User talk:Kraaabs|talk]]) 01:56, 7 November 2022 (UTC)<br />
<br />
=== Forcing Windows 7 onto a 66MHz CPU (Griffin) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' About 14 hours<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** The first entry to finish, I believe! They used 86box emulating a VIA Samuel, and a lot of trial and error to get the thing to boot at all. Was a fun one to watch. Nice and painful. [https://twitter.com/FOSSfirefighter/status/1588999569593208832 N tweeted about this one, too.] - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:02, 7 November 2022 (UTC)<br />
<br />
=== Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' <del>Ongoing</del> Failed :(<br />
* '''Duration:''' About 52 hours so far.<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** Yep, still going. It's been about 52 hours (~24-ish of which was prep work), and we're still decompressing the kernel on the Gentoo install CD. In for the long haul, this one. Being that I have to babysit this, is it active pain? There's a lot of waiting. Hybrid pain, maybe. :^) - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:06, 7 November 2022 (UTC)<br />
** It failed a while ago, I'm just lazy. Eventually it hit a timeout :'(. Oh well, it was fun. - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 22:46, 24 January 2023 (UTC)<br />
<br />
=== Compiling every major release of NetBSD on a SparcStation 2 (Daghdha) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 54 days (as of 2 Jan 2023)<br />
* '''Expected to Complete:''' 15 March 2023 (~73 days)<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread. Each release takes a week to build.<br />
<br />
=== Installing Windows 98 inside of Windows XP inside of Windows Vista inside of Windows 8 inside of Windows 10 (Autumn) ===<br />
<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 13 days (as of 1/12/23)<br />
* '''Proof:''' Discord live stream + milestones in the corresponding channel<br />
* '''Comments:''' <br />
** FFS the XP installer took 11 straight days to boot '''''TEXT MODE'''''... I am going to be in for a long wait on this one... - [[User:Autumnbreeze|Autumn]] ([[User talk:Autumnbreeze|talk]]) 12:13, 12 January 2023 (UTC)<br />
<br />
=== Compiling Rust on a Mac OS X 10.7 VM (Bridget) ===<br />
<br />
* '''Status''': Ongoing<br />
* '''Duration''': 3 hours (as of 2022-01-24 02:37 PM)<br />
* '''Proof''': Discord live stream + occasional milestones<br />
* '''Comments''':<br />
** Crap, I didn't tell Macports to download the source versions of the packages. :/ Still took an hour to install the binaries, so we're in for a wild ride here, huh? :P As of writing, it's installing the <code>ncurses</code> dependency. - [[User:Bridgetr|Bridget]] ([[User talk:Bridgetr|talk]]) 14:32, 24 January 2023 (UTC)<br />
<br />
== Active Pain ==<br />
Active Pain entries are livestreams or single projects that are actively worked on over the period of the competition. They can be over multiple sessions, with time being tallied up.<br />
<br />
=== Windows 98/ME on the Cursed 486 (NCommander) ===<br />
* '''Status:''' On Hiatus/Ongoing<br />
* '''Proof:''' https://www.youtube.com/watch?v=0uaINJAktLA (and messages in #content + Fedi)<br />
* '''Duration:''' Multiple attempts over multiple days, one 9 hour<br />
* '''Comments:'''<br />
** You can't install ME on 32 MiB of memory. Upgrades ordered. So far, Windows 98 First Edition was installed from floppies, second edition from Netware, and ME from NetWare and local install, with each attempt taking literal hours. [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 13:44, 2 January 2023 (UTC)<br />
<br />
=== Upgrading Through Every Version of OS/2 (NCommander) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' VoDs: https://www.youtube.com/watch?v=xeaRlhz96mI and https://www.youtube.com/watch?v=8uwGTHZzzF4<br />
* '''Duration:''' Approximately 22 Hours<br />
* '''Comments:''' <br />
** ow [[User:NCommander|- NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
<br />
=== Windows 10 in QEMU on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' Was live-updated on Discord, and also in the [https://picsofbread.com/potato-bread writeup here]<br />
* '''Duration:''' About 10 active hours, and about 18 more waiting for it to boot<br />
* '''Comments:''' <br />
** This was painful. Good way to spend a few days with COVID though. [[User:Kraaabs|- Kraaabs]] ([[User talk:Kraaabs|talk]]) 02:00, 7 November 2022 (UTC)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedrunning&diff=909Slow Computing Speedrunning2023-01-24T22:50:14Z<p>Kraaabs: fix signatures</p>
<hr />
<div>[[Category:Competition]]<br />
Welcome to the Slow Computing any% Speedrunning Contest; also known as watching digital paint dry.<br />
<br />
The goal of this contest is simple. To celebrate the long code [https://xkcd.com/303/] times, we're running an informal contest to celebrate this era of batch processing.<br />
<br />
== Objective and Rules ==<br />
<br />
It's pretty simple:<br />
* Using any vintage computer of your choice, perform a long-running task of some sort<br />
* Livestream, or otherwise provide regular status updates that show how far you have gotten.<br />
* Emulators and the like are A-OK; just let us know what it's doing.<br />
<br />
After each run, success or failure, our judges (which is mostly just the regulars in #paint-drying on [https://discord.gg/V8esNah Discord]) will deem what, if any titles such run has earned, and an entirely subjective place on the Wall of Pain. There are absolutely no prizes besides the knowledge that you might be immortalized here for the life of the wiki.<br />
<br />
Do you dare step up?<br />
<br />
=== Examples of projects ===<br />
For example, upgrading through every version of OS/2, building GCC, or the like. Livestream or otherwise regularly update the panting drying competition community. For NCommander's entries, VoDs on YouTube were provided. Europa livestreamed the terminal on Discord throughout the duration. Any sorta long running log with regular updates is acceptable.<br />
<br />
= The Wall of Pain =<br />
New categories will be added as needed<br />
<br />
== Idle Pain ==<br />
Idle Pain refers to tasks where they're started, and mostly left untouched until they finish (excluding minor tweaks, build failures, etc.)<br />
<br />
=== GCC 8 on an Ultra 5 running OpenBSD/sparc64 (Europa) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' Approximately 5.375 days (4.5 days GCC, 0.875 days CDE)<br />
* '''Proof:''' Livestreamed on Discord, updates periodically provided via Discord, [https://twitter.com/europa6502/status/1587304622749876224 Twitter], and Mastodon<br />
* '''Comments:'''<br />
** The build that started it all, Europa's attempt to install CDE which required upgrading GCC, and starting a multiday build process that lead to the creation of the paint drying community ... I'm still wondering how we got here - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
** It finished! She managed to build CDE with her new GCC after some help from NCommander, and is now working on configuring her newly built CDE! - [[User:Kraaabs|Kraaabs]] (([[User talk:Kraaabs|talk]]) 01:56, 7 November 2022 (UTC)<br />
<br />
=== Forcing Windows 7 onto a 66MHz CPU (Griffin) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' About 14 hours<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** The first entry to finish, I believe! They used 86box emulating a VIA Samuel, and a lot of trial and error to get the thing to boot at all. Was a fun one to watch. Nice and painful. [https://twitter.com/FOSSfirefighter/status/1588999569593208832 N tweeted about this one, too.] - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:02, 7 November 2022 (UTC)<br />
<br />
=== Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' <del>Ongoing</del> Failed :(<br />
* '''Duration:''' About 52 hours so far.<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** Yep, still going. It's been about 52 hours (~24-ish of which was prep work), and we're still decompressing the kernel on the Gentoo install CD. In for the long haul, this one. Being that I have to babysit this, is it active pain? There's a lot of waiting. Hybrid pain, maybe. :^) - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:06, 7 November 2022 (UTC)<br />
** It failed a while ago, I'm just lazy. Eventually it hit a timeout :'(. Oh well, it was fun. - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 22:46, 24 January 2023 (UTC)<br />
<br />
=== Compiling every major release of NetBSD on a SparcStation 2 (Daghdha) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 54 days (as of 2 Jan 2023)<br />
* '''Expected to Complete:''' 15 March 2023 (~73 days)<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread. Each release takes a week to build.<br />
<br />
=== Installing Windows 98 inside of Windows XP inside of Windows Vista inside of Windows 8 inside of Windows 10 (Autumn) ===<br />
<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 13 days (as of 1/12/23)<br />
* '''Proof:''' Discord live stream + milestones in the corresponding channel<br />
* '''Comments:''' <br />
** FFS the XP installer took 11 straight days to boot '''''TEXT MODE'''''... I am going to be in for a long wait on this one... - [[User:Autumnbreeze|Autumn]] (([[User talk:Autumnbreeze|talk]]) 12:13, 12 January 2023 (UTC)<br />
<br />
=== Compiling Rust on a Mac OS X 10.7 VM (Bridget) ===<br />
<br />
* '''Status''': Ongoing<br />
* '''Duration''': 3 hours (as of 2022-01-24 02:37 PM)<br />
* '''Proof''': Discord live stream + occasional milestones<br />
* '''Comments''':<br />
** Crap, I didn't tell Macports to download the source versions of the packages. :/ Still took an hour to install the binaries, so we're in for a wild ride here, huh? :P As of writing, it's installing the <code>ncurses</code> dependency. - [[User:Bridgetr|Bridget]] (([[User talk:Bridgetr|talk]]) 14:32, 24 January 2023 (UTC)<br />
<br />
== Active Pain ==<br />
Active Pain entries are livestreams or single projects that are actively worked on over the period of the competition. They can be over multiple sessions, with time being tallied up.<br />
<br />
=== Windows 98/ME on the Cursed 486 (NCommander) ===<br />
* '''Status:''' On Hiatus/Ongoing<br />
* '''Proof:''' https://www.youtube.com/watch?v=0uaINJAktLA (and messages in #content + Fedi)<br />
* '''Duration:''' Multiple attempts over multiple days, one 9 hour<br />
* '''Comments:'''<br />
** You can't install ME on 32 MiB of memory. Upgrades ordered. So far, Windows 98 First Edition was installed from floppies, second edition from Netware, and ME from NetWare and local install, with each attempt taking literal hours. [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 13:44, 2 January 2023 (UTC)<br />
<br />
=== Upgrading Through Every Version of OS/2 (NCommander) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' VoDs: https://www.youtube.com/watch?v=xeaRlhz96mI and https://www.youtube.com/watch?v=8uwGTHZzzF4<br />
* '''Duration:''' Approximately 22 Hours<br />
* '''Comments:''' <br />
** ow [[User:NCommander|- NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
<br />
=== Windows 10 in QEMU on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' Was live-updated on Discord, and also in the [https://picsofbread.com/potato-bread writeup here]<br />
* '''Duration:''' About 10 active hours, and about 18 more waiting for it to boot<br />
* '''Comments:''' <br />
** This was painful. Good way to spend a few days with COVID though. [[User:Kraaabs|- Kraaabs]] ([[User talk:Kraaabs|talk]]) 02:00, 7 November 2022 (UTC)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedrunning&diff=908Slow Computing Speedrunning2023-01-24T22:46:57Z<p>Kraaabs: /* Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) */</p>
<hr />
<div>[[Category:Competition]]<br />
Welcome to the Slow Computing any% Speedrunning Contest; also known as watching digital paint dry.<br />
<br />
The goal of this contest is simple. To celebrate the long code [https://xkcd.com/303/] times, we're running an informal contest to celebrate this era of batch processing.<br />
<br />
== Objective and Rules ==<br />
<br />
It's pretty simple:<br />
* Using any vintage computer of your choice, perform a long-running task of some sort<br />
* Livestream, or otherwise provide regular status updates that show how far you have gotten.<br />
* Emulators and the like are A-OK; just let us know what it's doing.<br />
<br />
After each run, success or failure, our judges (which is mostly just the regulars in #paint-drying on [https://discord.gg/V8esNah Discord]) will deem what, if any titles such run has earned, and an entirely subjective place on the Wall of Pain. There are absolutely no prizes besides the knowledge that you might be immortalized here for the life of the wiki.<br />
<br />
Do you dare step up?<br />
<br />
=== Examples of projects ===<br />
For example, upgrading through every version of OS/2, building GCC, or the like. Livestream or otherwise regularly update the panting drying competition community. For NCommander's entries, VoDs on YouTube were provided. Europa livestreamed the terminal on Discord throughout the duration. Any sorta long running log with regular updates is acceptable.<br />
<br />
= The Wall of Pain =<br />
New categories will be added as needed<br />
<br />
== Idle Pain ==<br />
Idle Pain refers to tasks where they're started, and mostly left untouched until they finish (excluding minor tweaks, build failures, etc.)<br />
<br />
=== GCC 8 on an Ultra 5 running OpenBSD/sparc64 (Europa) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' Approximately 5.375 days (4.5 days GCC, 0.875 days CDE)<br />
* '''Proof:''' Livestreamed on Discord, updates periodically provided via Discord, [https://twitter.com/europa6502/status/1587304622749876224 Twitter], and Mastodon<br />
* '''Comments:'''<br />
** The build that started it all, Europa's attempt to install CDE which required upgrading GCC, and starting a multiday build process that lead to the creation of the paint drying community ... I'm still wondering how we got here - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
** It finished! She managed to build CDE with her new GCC after some help from NCommander, and is now working on configuring her newly built CDE! - [[User:Kraaabs|Kraaabs]] (([[User talk:Kraaabs|talk]]) 01:56, 7 November 2022 (UTC)<br />
<br />
=== Forcing Windows 7 onto a 66MHz CPU (Griffin) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' About 14 hours<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** The first entry to finish, I believe! They used 86box emulating a VIA Samuel, and a lot of trial and error to get the thing to boot at all. Was a fun one to watch. Nice and painful. [https://twitter.com/FOSSfirefighter/status/1588999569593208832 N tweeted about this one, too.] - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:02, 7 November 2022 (UTC)<br />
<br />
=== Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' <del>Ongoing</del> Failed :(<br />
* '''Duration:''' About 52 hours so far.<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** Yep, still going. It's been about 52 hours (~24-ish of which was prep work), and we're still decompressing the kernel on the Gentoo install CD. In for the long haul, this one. Being that I have to babysit this, is it active pain? There's a lot of waiting. Hybrid pain, maybe. :^) - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:06, 7 November 2022 (UTC)<br />
** It failed a while ago, I'm just lazy. Eventually it hit a timeout :'(. Oh well, it was fun. - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 22:46, 24 January 2023 (UTC)<br />
<br />
=== Compiling every major release of NetBSD on a SparcStation 2 (Daghdha) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 54 days (as of 2 Jan 2023)<br />
* '''Expected to Complete:''' 15 March 2023 (~73 days)<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread. Each release takes a week to build.<br />
<br />
=== Installing Windows 98 inside of Windows XP inside of Windows Vista inside of Windows 8 inside of Windows 10 (Autumn) ===<br />
<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 13 days (as of 1/12/23)<br />
* '''Proof:''' Discord live stream + milestones in the corresponding channel<br />
* '''Comments:''' <br />
** [[Autumnbreeze|Autumn]] (12:13 1/12/23) FFS the XP installer took 11 straight days to boot '''''TEXT MODE'''''... I am going to be in for a long wait on this one...<br />
<br />
=== Compiling Rust on a Mac OS X 10.7 VM (Bridget) ===<br />
<br />
* '''Status''': Ongoing<br />
* '''Duration''': 3 hours (as of 2022-01-24 02:37 PM)<br />
* '''Proof''': Discord live stream + occasional milestones<br />
* '''Comments''':<br />
** Bridget (2:32 PM on 2022-01-24): Crap, I didn't tell Macports to download the source versions of the packages. :/ Still took an hour to install the binaries, so we're in for a wild ride here, huh? :P As of writing, it's installing the <code>ncurses</code> dependency.<br />
<br />
== Active Pain ==<br />
Active Pain entries are livestreams or single projects that are actively worked on over the period of the competition. They can be over multiple sessions, with time being tallied up.<br />
<br />
=== Windows 98/ME on the Cursed 486 (NCommander) ===<br />
* '''Status:''' On Hiatus/Ongoing<br />
* '''Proof:''' https://www.youtube.com/watch?v=0uaINJAktLA (and messages in #content + Fedi)<br />
* '''Duration:''' Multiple attempts over multiple days, one 9 hour<br />
* '''Comments:'''<br />
** You can't install ME on 32 MiB of memory. Upgrades ordered. So far, Windows 98 First Edition was installed from floppies, second edition from Netware, and ME from NetWare and local install, with each attempt taking literal hours. [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 13:44, 2 January 2023 (UTC)<br />
<br />
=== Upgrading Through Every Version of OS/2 (NCommander) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' VoDs: https://www.youtube.com/watch?v=xeaRlhz96mI and https://www.youtube.com/watch?v=8uwGTHZzzF4<br />
* '''Duration:''' Approximately 22 Hours<br />
* '''Comments:''' <br />
** ow [[User:NCommander|- NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
<br />
=== Windows 10 in QEMU on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' Was live-updated on Discord, and also in the [https://picsofbread.com/potato-bread writeup here]<br />
* '''Duration:''' About 10 active hours, and about 18 more waiting for it to boot<br />
* '''Comments:''' <br />
** This was painful. Good way to spend a few days with COVID though. [[User:Kraaabs|- Kraaabs]] ([[User talk:Kraaabs|talk]]) 02:00, 7 November 2022 (UTC)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Useful_Tools&diff=901Useful Tools2023-01-23T18:47:17Z<p>Kraaabs: </p>
<hr />
<div>== File System Manipulation ==<br />
* [https://github.com/aaru-dps/Aaru Aaru] supports a fairly comprehensive collection of disk image, partition table, and file system formats, and is built with the Microsoft .NET Framework - builds exist, for several operating systems.<br />
* [https://linux.die.net/man/8/kpartx kpartx] is a fairly standard command to automatically create loop devices for whole disk images (assuming regular partition table types Linux can understand)<br />
* [https://osxfuse.github.io/ macFUSE] allows you to use FUSE filesystems on macOS<br />
<br />
== Archive Manipulation == <br />
* 7-Zip supports the Windows Imaging format (<code>.WIM</code>) disk images, with LZX compression, as used by Windows 8.1<br />
* [https://github.com/MacPaw/XADMaster XADMaster] supports a fairly comprehensive collection of compression, and archival formats, and can also expand some disk image formats - this seems to be the basis of the "unar" utility, provided for Ubuntu, and some other Linux distributions.<br />
* [https://github.com/twogood/unshield unshield] is a CLI tool, for unpacking various flavours of InstallShield archive<br />
<br />
== Firmware Image Extraction ==<br />
* The [http://marksmods.com/Hack-the-L7/zip/random.zip RandomSHX] utility, for Windows will extract the contents of some Motorola P2K (e.g. A835) "UNIX Generated SuperFile" firmware archives - this requires Windows, and does not work with UNC paths<br />
* The <code>srecord</code> package, under Ubuntu contains a utility, that can convert Motorola S-Record files, into plain binaries: (for example <code>srec_cat C139_V1.0.03.E.m0 -Output C139_V1.0.03.E.bin -Binary</code><br />
<br />
* BinWalk is extremely useful, for extracting files, and resources out of firmware images, executables, and file system structures<br />
<br />
== Binary reverse engineering ==<br />
<br />
* [https://www.dependencywalker.com/ Dependency Walker] for understanding Windows program dependencies and what's used by the program, helpful for software archaeology.<br />
* [https://ghidra-sre.org/ Ghidra] is an open-source set of RE tools, including a set of decompilers and disassemblers for most binary formats.<br />
<br />
== Development tools ==<br />
* [https://github.com/davidgiven/ack The Amsterdam Compiler Kit] is one of the few (mostly) C99 compilers around that can still target a PDP-11 Unix v7 target.<br />
* [https://github.com/JuliaHubOSS/llvm-cbe llvm-cbe] is the C backend for LLVM -- it can convert LLVM bytecode into C (useful for compiling modern C++ targeting systems that don't have a functional modern C++ compiler, for example)<br />
<br />
[[Category:Preservation and Documentation]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Useful_Tools&diff=900Useful Tools2023-01-23T18:43:05Z<p>Kraaabs: /* Binary reverse engineering */</p>
<hr />
<div>== File System Manipulation ==<br />
* [https://github.com/aaru-dps/Aaru Aaru] supports a fairly comprehensive collection of disk image, partition table, and file system formats, and is built with the Microsoft .NET Framework - builds exist, for several operating systems.<br />
* [https://linux.die.net/man/8/kpartx kpartx] is a fairly standard command to automatically create loop devices for whole disk images (assuming regular partition table types Linux can understand)<br />
* [https://osxfuse.github.io/ macFUSE] allows you to use FUSE filesystems on macOS<br />
<br />
== Archive Manipulation == <br />
* 7-Zip supports the Windows Imaging format (<code>.WIM</code>) disk images, with LZX compression, as used by Windows 8.1<br />
* [https://github.com/MacPaw/XADMaster XADMaster] supports a fairly comprehensive collection of compression, and archival formats, and can also expand some disk image formats - this seems to be the basis of the "unar" utility, provided for Ubuntu, and some other Linux distributions.<br />
* [https://github.com/twogood/unshield unshield] is a CLI tool, for unpacking various flavours of InstallShield archive<br />
<br />
== Firmware Image Extraction ==<br />
* The [http://marksmods.com/Hack-the-L7/zip/random.zip RandomSHX] utility, for Windows will extract the contents of some Motorola P2K (e.g. A835) "UNIX Generated SuperFile" firmware archives - this requires Windows, and does not work with UNC paths<br />
* The <code>srecord</code> package, under Ubuntu contains a utility, that can convert Motorola S-Record files, into plain binaries: (for example <code>srec_cat C139_V1.0.03.E.m0 -Output C139_V1.0.03.E.bin -Binary</code><br />
<br />
* BinWalk is extremely useful, for extracting files, and resources out of firmware images, executables, and file system structures<br />
<br />
== Binary reverse engineering ==<br />
<br />
* [https://www.dependencywalker.com/ Dependency Walker] for understanding Windows program dependencies and what's used by the program, helpful for software archaeology.<br />
* [https://ghidra-sre.org/ Ghidra] is an open-source set of RE tools, including a set of decompilers and disassemblers for most binary formats.<br />
<br />
[[Category:Preservation and Documentation]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Useful_Tools&diff=899Useful Tools2023-01-23T18:41:17Z<p>Kraaabs: macFUSE</p>
<hr />
<div>== File System Manipulation ==<br />
* [https://github.com/aaru-dps/Aaru Aaru] supports a fairly comprehensive collection of disk image, partition table, and file system formats, and is built with the Microsoft .NET Framework - builds exist, for several operating systems.<br />
* [https://linux.die.net/man/8/kpartx kpartx] is a fairly standard command to automatically create loop devices for whole disk images (assuming regular partition table types Linux can understand)<br />
* [https://osxfuse.github.io/ macFUSE] allows you to use FUSE filesystems on macOS<br />
<br />
== Archive Manipulation == <br />
* 7-Zip supports the Windows Imaging format (<code>.WIM</code>) disk images, with LZX compression, as used by Windows 8.1<br />
* [https://github.com/MacPaw/XADMaster XADMaster] supports a fairly comprehensive collection of compression, and archival formats, and can also expand some disk image formats - this seems to be the basis of the "unar" utility, provided for Ubuntu, and some other Linux distributions.<br />
* [https://github.com/twogood/unshield unshield] is a CLI tool, for unpacking various flavours of InstallShield archive<br />
<br />
== Firmware Image Extraction ==<br />
* The [http://marksmods.com/Hack-the-L7/zip/random.zip RandomSHX] utility, for Windows will extract the contents of some Motorola P2K (e.g. A835) "UNIX Generated SuperFile" firmware archives - this requires Windows, and does not work with UNC paths<br />
* The <code>srecord</code> package, under Ubuntu contains a utility, that can convert Motorola S-Record files, into plain binaries: (for example <code>srec_cat C139_V1.0.03.E.m0 -Output C139_V1.0.03.E.bin -Binary</code><br />
<br />
* BinWalk is extremely useful, for extracting files, and resources out of firmware images, executables, and file system structures<br />
<br />
== Binary reverse engineering ==<br />
<br />
* Dependency Walker for understanding Windows program dependencies and what's used by the program, helpful for software archaeology.<br />
<br />
[[Category:Preservation and Documentation]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Useful_Tools&diff=898Useful Tools2023-01-23T18:39:22Z<p>Kraaabs: add kpartx ~Sarah</p>
<hr />
<div>== File System Manipulation ==<br />
* [https://github.com/aaru-dps/Aaru Aaru] supports a fairly comprehensive collection of disk image, partition table, and file system formats, and is built with the Microsoft .NET Framework - builds exist, for several operating systems.<br />
* [https://linux.die.net/man/8/kpartx kpartx] is a fairly standard command to automatically create loop devices for whole disk images (assuming regular partition table types Linux can understand)<br />
<br />
== Archive Manipulation == <br />
* 7-Zip supports the Windows Imaging format (<code>.WIM</code>) disk images, with LZX compression, as used by Windows 8.1<br />
* [https://github.com/MacPaw/XADMaster XADMaster] supports a fairly comprehensive collection of compression, and archival formats, and can also expand some disk image formats - this seems to be the basis of the "unar" utility, provided for Ubuntu, and some other Linux distributions.<br />
* [https://github.com/twogood/unshield unshield] is a CLI tool, for unpacking various flavours of InstallShield archive<br />
<br />
== Firmware Image Extraction ==<br />
* The [http://marksmods.com/Hack-the-L7/zip/random.zip RandomSHX] utility, for Windows will extract the contents of some Motorola P2K (e.g. A835) "UNIX Generated SuperFile" firmware archives - this requires Windows, and does not work with UNC paths<br />
* The <code>srecord</code> package, under Ubuntu contains a utility, that can convert Motorola S-Record files, into plain binaries: (for example <code>srec_cat C139_V1.0.03.E.m0 -Output C139_V1.0.03.E.bin -Binary</code><br />
<br />
* BinWalk is extremely useful, for extracting files, and resources out of firmware images, executables, and file system structures<br />
<br />
== Binary reverse engineering ==<br />
<br />
* Dependency Walker for understanding Windows program dependencies and what's used by the program, helpful for software archaeology.<br />
<br />
[[Category:Preservation and Documentation]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=864Project:Discord Bot Improvements2023-01-17T19:51:58Z<p>Kraaabs: /* Raconteur TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
Status: '''The bot is currently in development, and a prototype is nearing completion.'''<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# <del>See about using user permissions for the bot, rather than any moderator permissions</del> '''DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)'''<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# <del>Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)</del> '''DONE! (although I'm on the fence about including them in the JSON output. Boy howdy, base64 can get LARGE)'''<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API]) '''DONE! (I had to write my own MediaWiki API bindings. The bot can now create pages, and image uploads aren't far off.)'''<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Status: '''Tickets is currently being trialled on the main DisNCord server (good success so far)'''<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard -- but it's discord integrated<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
* UX is somewhat inconsistent and awkward<br />
* Piles up closed tickets as channels with no real archival<br />
* GDPR clause just says "contact us" with no other info<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
* Very polished interface<br />
* Deletes ticket channels when tickets are closed, but archives them in a thread for later viewing<br />
* Allows for the creation of custom forms and panels for ticket creation!<br />
==== Cons ====<br />
* Again, some features are paywalled (but nothing super essential...)<br />
* GDPR is handled through a discord server, which is... odd<br />
<br />
== Bot Infrastructure == <br />
<br />
Status: '''The Wiki and Fediverse servers are currently being moved. Afterwards, further discussion of bot hosting will be done.'''<br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=863Project:Discord Bot Improvements2023-01-17T19:51:41Z<p>Kraaabs: Update status of bot stuff ~Sarah</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
Status: '''The bot is currently in development, and a prototype is nearing completion.'''<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# <del>See about using user permissions for the bot, rather than any moderator permissions</del> '''DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)'''<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# <del>Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)</del> '''DONE! (although I'm on the fence about including them in the JSON output. Boy howdy, base64 can get LARGE)'''<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API]) '''DONE! (I had to write my own MediaWiki API bindings. The bot can now create pages, and image uploads aren't far off.'''<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Status: '''Tickets is currently being trialled on the main DisNCord server (good success so far)'''<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard -- but it's discord integrated<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
* UX is somewhat inconsistent and awkward<br />
* Piles up closed tickets as channels with no real archival<br />
* GDPR clause just says "contact us" with no other info<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
* Very polished interface<br />
* Deletes ticket channels when tickets are closed, but archives them in a thread for later viewing<br />
* Allows for the creation of custom forms and panels for ticket creation!<br />
==== Cons ====<br />
* Again, some features are paywalled (but nothing super essential...)<br />
* GDPR is handled through a discord server, which is... odd<br />
<br />
== Bot Infrastructure == <br />
<br />
Status: '''The Wiki and Fediverse servers are currently being moved. Afterwards, further discussion of bot hosting will be done.'''<br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Wiki_Contribution_Guide&diff=854Project:Wiki Contribution Guide2023-01-17T00:54:29Z<p>Kraaabs: /* How this wiki is used (licensing) */</p>
<hr />
<div>[[Category:Wiki Docs]]<br />
<br />
This page aims to serve as a guide for contributing to the DisNCord Community Wiki. There are some important things to know and guidelines to keep in mind when writing or editing wiki pages that'll help make everyone's lives easier, and keep the wiki clean and organized (and most importantly, consistent!)<br />
<br />
== Creating Pages ==<br />
<br />
The most important thing on any wiki is the pages. Good quality pages with clear topics are encouraged. If you have any questions, ask!<br />
<br />
=== What should be a page? ===<br />
<br />
Generally speaking, if there's something you know about that's mostly undocumented elsewhere and you want to take the steps to gather information about it and create a solid central source of information, do it! Anyone who's worked with older or more obscure technology knows that sometimes information is lost to time or hopelessly scattered about. Every little bit helps!<br />
<br />
If something is your own personal project, it can get a wiki page too. If you've got something concrete and it's generally related to the type of preservation/exploration that DisNCord/Restless Systems tends to dabble in, it's certainly welcome. If you don't know if something of yours should get a wiki page, or if you have any doubts, feel free to ask a mod.<br />
<br />
== Categorization ==<br />
<br />
MediaWiki features two mostly unrelated category systems. If you're not used to working with MediaWiki-based wikis, it can be confusing to tell the difference between the two.<br />
<br />
=== Namespaces ===<br />
<br />
Namespaces are the first type of category that we use on this wiki. You'll know if a page is namespaced by looking for a prefix in the page title. For instance, this page is in the <code>Project:</code> namespace.<br />
<br />
Namespaces are generally used here for specific purposes. Things in the <code>Project:</code> namespace are generally related to the wiki, Mastodon, or Discord themselves, and can be seen as more "meta" articles. Pages in the <code>Category:</code> namespace are... well, categories. There are other namespaces too, such as <code>Help:</code>, but those aren't often used manually.<br />
<br />
An important thing to note is that '''namespaces are not to be used for ordinary pages!''' The way MediaWiki presents them is confusing, but they are not categories, and namespaced pages don't show up properly in searches, etc. Categories should be used for categorizing pages instead.<br />
<br />
=== Categories ===<br />
<br />
Categories are the primary type of category used for pages. These have no special prefixes or suffixes appended to page titles, and the categories a page uses can be viewed on the right hand side next to the page content (on desktop). Every category ''should'' have a landing page in the <code>Category:</code> namespace that serves as an auto-generated directory of pages within the category. See [https://restless.systems/wiki/Category:Preservation_and_Documentation Category:Preservation and Documentation] <!-- note: we can't link to category pages normally because of the way category tagging works... --> as an example.<br />
<br />
To categorize a page, simply add a link to the category page in your WikiText source. For example, adding <code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> to your markup will place your page in the Preservation and Documentation category.<br />
<br />
==== Categories currently in use ====<br />
<br />
<code><nowiki>[[Category:Wiki Docs]]</nowiki></code> - documentation relating to how to use the wiki<br><br />
<code><nowiki>[[Category:Competition]]</nowiki></code> - competitions held on Discord or elsewhere<br><br />
<code><nowiki>[[Category:Discord]]</nowiki></code> - pages related to the operation of the DisNCord server<br><br />
<code><nowiki>[[Category:Discussion Logs]]</nowiki></code> - logs of conversations on DisNCord that may have valuable information<br><br />
<code><nowiki>[[Category:Fluff]]</nowiki></code> - fun stuff<br><br />
<code><nowiki>[[Category:History]]</nowiki></code> - history of specific machines, software, or events<br><br />
<code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> - pages related to preservation efforts<br><br />
<code><nowiki>[[Category:OS/2]]</nowiki></code> - pages related to the ongoing research into OS/2 being performed by [[User:NCommander]] and others<br />
<br />
Other categories may be added as needed. Please ask before adding your page to a brand new category -- a category with only one page is rarely useful, so ask yourself if your page can fit into one of the existing categories. If enough pages build up that they might need their own categorization, feel free to bring it up in the Discord #wiki-bootstrap channel. (This is why we have an OS/2 category, after all)<br />
<br />
== Page Etiquette == <br />
<br />
One key thing to keep in mind in order to keep the wiki organized is the tone and style of pages. <br />
<br />
=== Citation ===<br />
<br />
Remember to cite your sources! Primary knowledge is fine, but cited information is far better. [https://www.mediawiki.org/wiki/Help:Cite MediaWiki has a citation system] that is fairly easy to use, and it's easier to cite as you go, rather than go back and add citations.<br />
<br />
=== Should this be multiple pages? ===<br />
<br />
Consider if the topic you're writing about should be multiple pages. Some topics, such as [[Research Stream: OS/2 1.0 Explorations]] make more sense as a large monolithic page. Other topics, such as the OS/2 and MDOS executable formats ([[Linear Executable]], [[New Executable]]) make sense as separate articles from the main [[Multitasking DOS 4]] page.<br />
<br />
In general, individual topics or technologies should get their own page. This is better for discoverability, and it also makes it easier to reference this wiki properly. Think of it this way: if you're looking for information on an obscure executable format, would you rather look at the page titled [[New Executable]], or an entire textbook titled "OS/2 Internals"?<br />
<br />
=== Style guide ===<br />
<br />
A formal style guide shouldn't be strictly necessary, as everyone has differing writing styles, and not everyone is a native English speaker. However, a few notes:<br />
<br />
* Use paragraphs! In general, paragraph breaks should be frequent, and each paragraph should be a separate topic, event, or idea. Look at how Wikipedia does things for a good example. This keeps things easy to read, and easy on the eyes.<br />
* Use sections! Using sections (<code>== Primary Section ==</code>, <code>=== Secondary Section ===</code>, <code>==== Tertiary Section ====</code>) does two things. Firstly, it breaks the page up visually, making it easy to find key information quickly. Secondly, it generates a nice table of contents at the start of the page. This aids in navigation, and makes it easy to link to different sections of the page!<br />
* Write from as neutral of a tone as possible. Think of this as an encyclopedia of sorts. Opinions are welcome, and bias happens, but write objectively if at all possible. We want to present information most of all.<br />
<br />
== How this wiki is used (licensing) ==<br />
<br />
This wiki is tentatively licensed under [https://creativecommons.org/licenses/by-sa/4.0/ CC-BY-SA 4.0]. This is a similar license to the one that Wikipedia uses, and in general, usage falls under the same terms. Any content directly added to this wiki must be released either under the terms of the license, or under terms compatible with it. Essentially, CC-BY-SA states:<br />
<br />
* You are free to share content from this wiki as you wish, including derivative works.<br />
* However, any derivative works MUST credit the original author of the work, and MUST be shared under the same license as the work.<br />
<br />
Essentially, this means that if you directly take anything from this wiki, the original author must be credited, and your work must also be CC-BY-SA 4.0.<br />
<br />
Currently, we're evaluating whether CC-BY-SA is the best choice for the wiki. The license may be subject to change. <br />
<br />
=== Use of this wiki by NCommander ===<br />
<br />
You can think of this wiki sort of like [[User:NCommander]]'s project notebook of sorts. Anything written here has the potential to be used elsewhere in a video or a stream, and you're essentially giving permission for them or anyone who comes across the wiki to use the information as they please. Sharing is caring, and the spread of information is always a good thing!<br />
<br />
=== Copyrighted Materials ===<br />
<br />
Being a wiki that often delves into software and hardware preservation, the issue of copyrighted content is bound to come up. Generally speaking, '''ASK.''' We cannot host or link to any copyrighted materials in general. (Abandonware is still copyrighted!)<br />
<br />
The current understanding is that it's okay to make people aware that such things can be found. For example, saying "here's a link to X and Y on the Internet Archive" is NOT okay, but "you can find X and Y easily by searching on the Internet Archive" IS okay. ''Mentioning'' copyrighted content is fine, just don't give too many specifics on acquisition. This follows a similar policy to the Discord server.</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Wiki_Contribution_Guide&diff=853Project:Wiki Contribution Guide2023-01-17T00:52:47Z<p>Kraaabs: missing line break ~Sarah</p>
<hr />
<div>[[Category:Wiki Docs]]<br />
<br />
This page aims to serve as a guide for contributing to the DisNCord Community Wiki. There are some important things to know and guidelines to keep in mind when writing or editing wiki pages that'll help make everyone's lives easier, and keep the wiki clean and organized (and most importantly, consistent!)<br />
<br />
== Creating Pages ==<br />
<br />
The most important thing on any wiki is the pages. Good quality pages with clear topics are encouraged. If you have any questions, ask!<br />
<br />
=== What should be a page? ===<br />
<br />
Generally speaking, if there's something you know about that's mostly undocumented elsewhere and you want to take the steps to gather information about it and create a solid central source of information, do it! Anyone who's worked with older or more obscure technology knows that sometimes information is lost to time or hopelessly scattered about. Every little bit helps!<br />
<br />
If something is your own personal project, it can get a wiki page too. If you've got something concrete and it's generally related to the type of preservation/exploration that DisNCord/Restless Systems tends to dabble in, it's certainly welcome. If you don't know if something of yours should get a wiki page, or if you have any doubts, feel free to ask a mod.<br />
<br />
== Categorization ==<br />
<br />
MediaWiki features two mostly unrelated category systems. If you're not used to working with MediaWiki-based wikis, it can be confusing to tell the difference between the two.<br />
<br />
=== Namespaces ===<br />
<br />
Namespaces are the first type of category that we use on this wiki. You'll know if a page is namespaced by looking for a prefix in the page title. For instance, this page is in the <code>Project:</code> namespace.<br />
<br />
Namespaces are generally used here for specific purposes. Things in the <code>Project:</code> namespace are generally related to the wiki, Mastodon, or Discord themselves, and can be seen as more "meta" articles. Pages in the <code>Category:</code> namespace are... well, categories. There are other namespaces too, such as <code>Help:</code>, but those aren't often used manually.<br />
<br />
An important thing to note is that '''namespaces are not to be used for ordinary pages!''' The way MediaWiki presents them is confusing, but they are not categories, and namespaced pages don't show up properly in searches, etc. Categories should be used for categorizing pages instead.<br />
<br />
=== Categories ===<br />
<br />
Categories are the primary type of category used for pages. These have no special prefixes or suffixes appended to page titles, and the categories a page uses can be viewed on the right hand side next to the page content (on desktop). Every category ''should'' have a landing page in the <code>Category:</code> namespace that serves as an auto-generated directory of pages within the category. See [https://restless.systems/wiki/Category:Preservation_and_Documentation Category:Preservation and Documentation] <!-- note: we can't link to category pages normally because of the way category tagging works... --> as an example.<br />
<br />
To categorize a page, simply add a link to the category page in your WikiText source. For example, adding <code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> to your markup will place your page in the Preservation and Documentation category.<br />
<br />
==== Categories currently in use ====<br />
<br />
<code><nowiki>[[Category:Wiki Docs]]</nowiki></code> - documentation relating to how to use the wiki<br><br />
<code><nowiki>[[Category:Competition]]</nowiki></code> - competitions held on Discord or elsewhere<br><br />
<code><nowiki>[[Category:Discord]]</nowiki></code> - pages related to the operation of the DisNCord server<br><br />
<code><nowiki>[[Category:Discussion Logs]]</nowiki></code> - logs of conversations on DisNCord that may have valuable information<br><br />
<code><nowiki>[[Category:Fluff]]</nowiki></code> - fun stuff<br><br />
<code><nowiki>[[Category:History]]</nowiki></code> - history of specific machines, software, or events<br><br />
<code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> - pages related to preservation efforts<br><br />
<code><nowiki>[[Category:OS/2]]</nowiki></code> - pages related to the ongoing research into OS/2 being performed by [[User:NCommander]] and others<br />
<br />
Other categories may be added as needed. Please ask before adding your page to a brand new category -- a category with only one page is rarely useful, so ask yourself if your page can fit into one of the existing categories. If enough pages build up that they might need their own categorization, feel free to bring it up in the Discord #wiki-bootstrap channel. (This is why we have an OS/2 category, after all)<br />
<br />
== Page Etiquette == <br />
<br />
One key thing to keep in mind in order to keep the wiki organized is the tone and style of pages. <br />
<br />
=== Citation ===<br />
<br />
Remember to cite your sources! Primary knowledge is fine, but cited information is far better. [https://www.mediawiki.org/wiki/Help:Cite MediaWiki has a citation system] that is fairly easy to use, and it's easier to cite as you go, rather than go back and add citations.<br />
<br />
=== Should this be multiple pages? ===<br />
<br />
Consider if the topic you're writing about should be multiple pages. Some topics, such as [[Research Stream: OS/2 1.0 Explorations]] make more sense as a large monolithic page. Other topics, such as the OS/2 and MDOS executable formats ([[Linear Executable]], [[New Executable]]) make sense as separate articles from the main [[Multitasking DOS 4]] page.<br />
<br />
In general, individual topics or technologies should get their own page. This is better for discoverability, and it also makes it easier to reference this wiki properly. Think of it this way: if you're looking for information on an obscure executable format, would you rather look at the page titled [[New Executable]], or an entire textbook titled "OS/2 Internals"?<br />
<br />
=== Style guide ===<br />
<br />
A formal style guide shouldn't be strictly necessary, as everyone has differing writing styles, and not everyone is a native English speaker. However, a few notes:<br />
<br />
* Use paragraphs! In general, paragraph breaks should be frequent, and each paragraph should be a separate topic, event, or idea. Look at how Wikipedia does things for a good example. This keeps things easy to read, and easy on the eyes.<br />
* Use sections! Using sections (<code>== Primary Section ==</code>, <code>=== Secondary Section ===</code>, <code>==== Tertiary Section ====</code>) does two things. Firstly, it breaks the page up visually, making it easy to find key information quickly. Secondly, it generates a nice table of contents at the start of the page. This aids in navigation, and makes it easy to link to different sections of the page!<br />
* Write from as neutral of a tone as possible. Think of this as an encyclopedia of sorts. Opinions are welcome, and bias happens, but write objectively if at all possible. We want to present information most of all.<br />
<br />
== How this wiki is used (licensing) ==<br />
<br />
This wiki is tentatively licensed under [https://creativecommons.org/licenses/by-sa/4.0/ CC-BY-SA 4.0]. This is a similar license to the one that Wikipedia uses, and in general, usage falls under the same terms. Any content directly added to this wiki must be released either under the terms of the license, or under terms compatible with it. Essentially, CC-BY-SA states:<br />
<br />
* You are free to share content from this wiki as you wish, including derivative works.<br />
* However, any derivative works MUST credit the original author of the work, and MUST be shared under the same license as the work.<br />
<br />
Essentially, this means that if you directly take anything from this wiki, the original author must be credited, and your work must also be CC-BY-SA 4.0. <br />
<br />
=== Use of this wiki by NCommander ===<br />
<br />
You can think of this wiki sort of like [[User:NCommander]]'s project notebook of sorts. Anything written here has the potential to be used elsewhere in a video or a stream, and you're essentially giving permission for them or anyone who comes across the wiki to use the information as they please. Sharing is caring, and the spread of information is always a good thing!<br />
<br />
=== Copyrighted Materials ===<br />
<br />
Being a wiki that often delves into software and hardware preservation, the issue of copyrighted content is bound to come up. Generally speaking, '''ASK.''' We cannot host or link to any copyrighted materials in general. (Abandonware is still copyrighted!)<br />
<br />
The current understanding is that it's okay to make people aware that such things can be found. For example, saying "here's a link to X and Y on the Internet Archive" is NOT okay, but "you can find X and Y easily by searching on the Internet Archive" IS okay. ''Mentioning'' copyrighted content is fine, just don't give too many specifics on acquisition. This follows a similar policy to the Discord server.</div>Kraaabshttps://wiki.restless.systems/index.php?title=Category:Wiki_Docs&diff=852Category:Wiki Docs2023-01-17T00:50:54Z<p>Kraaabs: Add landing page for new Wiki Docs category ~Sarah</p>
<hr />
<div>This category contains pages documenting how to use and contribute to this wiki.</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Wiki_Contribution_Guide&diff=851Project:Wiki Contribution Guide2023-01-17T00:50:24Z<p>Kraaabs: Adding an initial draft of a set of guidelines for wiki contributions ~Sarah</p>
<hr />
<div>[[Category:Wiki Docs]]<br />
<br />
This page aims to serve as a guide for contributing to the DisNCord Community Wiki. There are some important things to know and guidelines to keep in mind when writing or editing wiki pages that'll help make everyone's lives easier, and keep the wiki clean and organized (and most importantly, consistent!)<br />
<br />
== Creating Pages ==<br />
<br />
The most important thing on any wiki is the pages. Good quality pages with clear topics are encouraged. If you have any questions, ask!<br />
<br />
=== What should be a page? ===<br />
<br />
Generally speaking, if there's something you know about that's mostly undocumented elsewhere and you want to take the steps to gather information about it and create a solid central source of information, do it! Anyone who's worked with older or more obscure technology knows that sometimes information is lost to time or hopelessly scattered about. Every little bit helps!<br />
<br />
If something is your own personal project, it can get a wiki page too. If you've got something concrete and it's generally related to the type of preservation/exploration that DisNCord/Restless Systems tends to dabble in, it's certainly welcome. If you don't know if something of yours should get a wiki page, or if you have any doubts, feel free to ask a mod.<br />
<br />
== Categorization ==<br />
<br />
MediaWiki features two mostly unrelated category systems. If you're not used to working with MediaWiki-based wikis, it can be confusing to tell the difference between the two.<br />
<br />
=== Namespaces ===<br />
<br />
Namespaces are the first type of category that we use on this wiki. You'll know if a page is namespaced by looking for a prefix in the page title. For instance, this page is in the <code>Project:</code> namespace.<br />
<br />
Namespaces are generally used here for specific purposes. Things in the <code>Project:</code> namespace are generally related to the wiki, Mastodon, or Discord themselves, and can be seen as more "meta" articles. Pages in the <code>Category:</code> namespace are... well, categories. There are other namespaces too, such as <code>Help:</code>, but those aren't often used manually.<br />
<br />
An important thing to note is that '''namespaces are not to be used for ordinary pages!''' The way MediaWiki presents them is confusing, but they are not categories, and namespaced pages don't show up properly in searches, etc. Categories should be used for categorizing pages instead.<br />
<br />
=== Categories ===<br />
<br />
Categories are the primary type of category used for pages. These have no special prefixes or suffixes appended to page titles, and the categories a page uses can be viewed on the right hand side next to the page content (on desktop). Every category ''should'' have a landing page in the <code>Category:</code> namespace that serves as an auto-generated directory of pages within the category. See [https://restless.systems/wiki/Category:Preservation_and_Documentation Category:Preservation and Documentation] <!-- note: we can't link to category pages normally because of the way category tagging works... --> as an example.<br />
<br />
To categorize a page, simply add a link to the category page in your WikiText source. For example, adding <code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> to your markup will place your page in the Preservation and Documentation category.<br />
<br />
==== Categories currently in use ====<br />
<br />
<code><nowiki>[[Category:Wiki Docs]]</nowiki></code> - documentation relating to how to use the wiki<br />
<code><nowiki>[[Category:Competition]]</nowiki></code> - competitions held on Discord or elsewhere<br><br />
<code><nowiki>[[Category:Discord]]</nowiki></code> - pages related to the operation of the DisNCord server<br><br />
<code><nowiki>[[Category:Discussion Logs]]</nowiki></code> - logs of conversations on DisNCord that may have valuable information<br><br />
<code><nowiki>[[Category:Fluff]]</nowiki></code> - fun stuff<br><br />
<code><nowiki>[[Category:History]]</nowiki></code> - history of specific machines, software, or events<br><br />
<code><nowiki>[[Category:Preservation and Documentation]]</nowiki></code> - pages related to preservation efforts<br><br />
<code><nowiki>[[Category:OS/2]]</nowiki></code> - pages related to the ongoing research into OS/2 being performed by [[User:NCommander]] and others<br />
<br />
Other categories may be added as needed. Please ask before adding your page to a brand new category -- a category with only one page is rarely useful, so ask yourself if your page can fit into one of the existing categories. If enough pages build up that they might need their own categorization, feel free to bring it up in the Discord #wiki-bootstrap channel. (This is why we have an OS/2 category, after all)<br />
<br />
== Page Etiquette == <br />
<br />
One key thing to keep in mind in order to keep the wiki organized is the tone and style of pages. <br />
<br />
=== Citation ===<br />
<br />
Remember to cite your sources! Primary knowledge is fine, but cited information is far better. [https://www.mediawiki.org/wiki/Help:Cite MediaWiki has a citation system] that is fairly easy to use, and it's easier to cite as you go, rather than go back and add citations.<br />
<br />
=== Should this be multiple pages? ===<br />
<br />
Consider if the topic you're writing about should be multiple pages. Some topics, such as [[Research Stream: OS/2 1.0 Explorations]] make more sense as a large monolithic page. Other topics, such as the OS/2 and MDOS executable formats ([[Linear Executable]], [[New Executable]]) make sense as separate articles from the main [[Multitasking DOS 4]] page.<br />
<br />
In general, individual topics or technologies should get their own page. This is better for discoverability, and it also makes it easier to reference this wiki properly. Think of it this way: if you're looking for information on an obscure executable format, would you rather look at the page titled [[New Executable]], or an entire textbook titled "OS/2 Internals"?<br />
<br />
=== Style guide ===<br />
<br />
A formal style guide shouldn't be strictly necessary, as everyone has differing writing styles, and not everyone is a native English speaker. However, a few notes:<br />
<br />
* Use paragraphs! In general, paragraph breaks should be frequent, and each paragraph should be a separate topic, event, or idea. Look at how Wikipedia does things for a good example. This keeps things easy to read, and easy on the eyes.<br />
* Use sections! Using sections (<code>== Primary Section ==</code>, <code>=== Secondary Section ===</code>, <code>==== Tertiary Section ====</code>) does two things. Firstly, it breaks the page up visually, making it easy to find key information quickly. Secondly, it generates a nice table of contents at the start of the page. This aids in navigation, and makes it easy to link to different sections of the page!<br />
* Write from as neutral of a tone as possible. Think of this as an encyclopedia of sorts. Opinions are welcome, and bias happens, but write objectively if at all possible. We want to present information most of all.<br />
<br />
== How this wiki is used (licensing) ==<br />
<br />
This wiki is tentatively licensed under [https://creativecommons.org/licenses/by-sa/4.0/ CC-BY-SA 4.0]. This is a similar license to the one that Wikipedia uses, and in general, usage falls under the same terms. Any content directly added to this wiki must be released either under the terms of the license, or under terms compatible with it. Essentially, CC-BY-SA states:<br />
<br />
* You are free to share content from this wiki as you wish, including derivative works.<br />
* However, any derivative works MUST credit the original author of the work, and MUST be shared under the same license as the work.<br />
<br />
Essentially, this means that if you directly take anything from this wiki, the original author must be credited, and your work must also be CC-BY-SA 4.0. <br />
<br />
=== Use of this wiki by NCommander ===<br />
<br />
You can think of this wiki sort of like [[User:NCommander]]'s project notebook of sorts. Anything written here has the potential to be used elsewhere in a video or a stream, and you're essentially giving permission for them or anyone who comes across the wiki to use the information as they please. Sharing is caring, and the spread of information is always a good thing!<br />
<br />
=== Copyrighted Materials ===<br />
<br />
Being a wiki that often delves into software and hardware preservation, the issue of copyrighted content is bound to come up. Generally speaking, '''ASK.''' We cannot host or link to any copyrighted materials in general. (Abandonware is still copyrighted!)<br />
<br />
The current understanding is that it's okay to make people aware that such things can be found. For example, saying "here's a link to X and Y on the Internet Archive" is NOT okay, but "you can find X and Y easily by searching on the Internet Archive" IS okay. ''Mentioning'' copyrighted content is fine, just don't give too many specifics on acquisition. This follows a similar policy to the Discord server.</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedruning&diff=709Slow Computing Speedruning2023-01-12T15:40:15Z<p>Kraaabs: Kraaabs moved page Slow Computing Speedruning to Slow Computing Speedrunning: Cleaning page titles</p>
<hr />
<div>#REDIRECT [[Slow Computing Speedrunning]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Slow_Computing_Speedrunning&diff=708Slow Computing Speedrunning2023-01-12T15:40:15Z<p>Kraaabs: Kraaabs moved page Slow Computing Speedruning to Slow Computing Speedrunning: Cleaning page titles</p>
<hr />
<div>[[Category:Competition]]<br />
Welcome to the Slow Computing any% Speedrunning Contest; also known as watching digital paint dry.<br />
<br />
The goal of this contest is simple. To celebrate the long code [https://xkcd.com/303/] times, we're running an informal contest to celebrate this era of batch processing.<br />
<br />
== Objective and Rules ==<br />
<br />
It's pretty simple:<br />
* Using any vintage computer of your choice, perform a long-running task of some sort<br />
* Livestream, or otherwise provide regular status updates that show how far you have gotten.<br />
* Emulators and the like are A-OK; just let us know what it's doing.<br />
<br />
After each run, success or failure, our judges (which is mostly just the regulars in #paint-drying on [https://discord.gg/V8esNah Discord]) will deem what, if any titles such run has earned, and an entirely subjective place on the Wall of Pain. There are absolutely no prizes besides the knowledge that you might be immortalized here for the life of the wiki.<br />
<br />
Do you dare step up?<br />
<br />
=== Examples of projects ===<br />
For example, upgrading through every version of OS/2, building GCC, or the like. Livestream or otherwise regularly update the panting drying competition community. For NCommander's entries, VoDs on YouTube were provided. Europa livestreamed the terminal on Discord throughout the duration. Any sorta long running log with regular updates is acceptable.<br />
<br />
= The Wall of Pain =<br />
New categories will be added as needed<br />
<br />
== Idle Pain ==<br />
Idle Pain refers to tasks where they're started, and mostly left untouched until they finish (excluding minor tweaks, build failures, etc.)<br />
<br />
=== GCC 8 on an Ultra 5 running OpenBSD/sparc64 (Europa) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' Approximately 5.375 days (4.5 days GCC, 0.875 days CDE)<br />
* '''Proof:''' Livestreamed on Discord, updates periodically provided via Discord, [https://twitter.com/europa6502/status/1587304622749876224 Twitter], and Mastodon<br />
* '''Comments:'''<br />
** The build that started it all, Europa's attempt to install CDE which required upgrading GCC, and starting a multiday build process that lead to the creation of the paint drying community ... I'm still wondering how we got here - [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
** It finished! She managed to build CDE with her new GCC after some help from NCommander, and is now working on configuring her newly built CDE! - [[User:Kraaabs|Kraaabs]] (([[User talk:Kraaabs|talk]]) 01:56, 7 November 2022 (UTC)<br />
<br />
=== Forcing Windows 7 onto a 66MHz CPU (Griffin) ===<br />
* '''Status:''' Complete!<br />
* '''Duration:''' About 14 hours<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** The first entry to finish, I believe! They used 86box emulating a VIA Samuel, and a lot of trial and error to get the thing to boot at all. Was a fun one to watch. Nice and painful. [https://twitter.com/FOSSfirefighter/status/1588999569593208832 N tweeted about this one, too.] - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:02, 7 November 2022 (UTC)<br />
<br />
=== Installing Gentoo in DOSBochs in QEMU on Void Linux on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' About 52 hours so far.<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread<br />
* '''Comments:'''<br />
** Yep, still going. It's been about 52 hours (~24-ish of which was prep work), and we're still decompressing the kernel on the Gentoo install CD. In for the long haul, this one. Being that I have to babysit this, is it active pain? There's a lot of waiting. Hybrid pain, maybe. :^) - [[User:Kraaabs|Kraaabs]] ([[User talk:Kraaabs|talk]]) 03:06, 7 November 2022 (UTC)<br />
<br />
=== Compiling every major release of NetBSD on a SparcStation 2 (Daghdha) ===<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 54 days (as of 2 Jan 2023)<br />
* '''Expected to Complete:''' 15 March 2023 (~73 days)<br />
* '''Proof:''' Livestreamed on Discord, and live-updated in a Discord thread. Each release takes a week to build.<br />
<br />
=== Installing Windows 98 inside of Windows XP inside of Windows Vista inside of Windows 8 inside of Windows 10 (Autumn) ===<br />
<br />
* '''Status:''' Ongoing<br />
* '''Duration:''' 13 days (as of 1/12/23)<br />
* '''Proof:''' Discord live stream + milestones in the corresponding channel<br />
* '''Comments:''' <br />
** [[Autumnbreeze|Autumn]] (12:13 1/12/23) FFS the XP installer took 11 straight days to boot '''''TEXT MODE'''''... I am going to be in for a long wait on this one...<br />
<br />
== Active Pain ==<br />
Active Pain entries are livestreams or single projects that are actively worked on over the period of the competition. They can be over multiple sessions, with time being tallied up.<br />
<br />
=== Windows 98/ME on the Cursed 486 (NCommander) ===<br />
* '''Status:''' On Hiatus/Ongoing<br />
* '''Proof:''' https://www.youtube.com/watch?v=0uaINJAktLA (and messages in #content + Fedi)<br />
* '''Duration:''' Multiple attempts over multiple days, one 9 hour<br />
* '''Comments:'''<br />
** You can't install ME on 32 MiB of memory. Upgrades ordered. So far, Windows 98 First Edition was installed from floppies, second edition from Netware, and ME from NetWare and local install, with each attempt taking literal hours. [[User:NCommander|NCommander]] ([[User talk:NCommander|talk]]) 13:44, 2 January 2023 (UTC)<br />
<br />
=== Upgrading Through Every Version of OS/2 (NCommander) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' VoDs: https://www.youtube.com/watch?v=xeaRlhz96mI and https://www.youtube.com/watch?v=8uwGTHZzzF4<br />
* '''Duration:''' Approximately 22 Hours<br />
* '''Comments:''' <br />
** ow [[User:NCommander|- NCommander]] ([[User talk:NCommander|talk]]) 14:54, 4 November 2022 (UTC)<br />
<br />
=== Windows 10 in QEMU on a PowerBook G4 (Krabs) ===<br />
* '''Status:''' Complete/Historical<br />
*'''Proof:''' Was live-updated on Discord, and also in the [https://picsofbread.com/potato-bread writeup here]<br />
* '''Duration:''' About 10 active hours, and about 18 more waiting for it to boot<br />
* '''Comments:''' <br />
** This was painful. Good way to spend a few days with COVID though. [[User:Kraaabs|- Kraaabs]] ([[User talk:Kraaabs|talk]]) 02:00, 7 November 2022 (UTC)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Research_Stream_Summarys&diff=707Research Stream Summarys2023-01-12T15:39:58Z<p>Kraaabs: Kraaabs moved page Research Stream Summarys to Research Stream Summaries: Cleaning page titles</p>
<hr />
<div>#REDIRECT [[Research Stream Summaries]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Research_Stream_Summaries&diff=706Research Stream Summaries2023-01-12T15:39:58Z<p>Kraaabs: Kraaabs moved page Research Stream Summarys to Research Stream Summaries: Cleaning page titles</p>
<hr />
<div>[[Category:Projects]]<br />
This documents the various research streams done, both past and present.<br />
<br />
== OS/2 Research Streams ==<br />
These are the streams that specifically deal with documenting a specific part of OS/2's backstory, or in-depth review of a specific topic.<br />
<br />
=== What Was OS/2 Intended To Be ===<br />
These streams will form the "What is OS/2" Realtime Video<br />
<br />
* Multiuser DOS 4 Exploration<br />
* [[Early OS/2 Explorations|OS/2 1.0 Exploration]]<br />
* Presentation Manager<br />
<br />
=== Researching Technical Aspects Of The System ===<br />
* Did the 80286 Hamstring OS/2?<br />
* OS/2 DOS Box Testing<br />
* GDI vs. GPI<br />
<br />
== Old NCommander Streams ==<br />
The following should probably be written up at some point<br />
<br />
* [[3D Movie Maker Compilation]]<br />
* [[Amiga UNIX]]<br />
* [[NT POSIX subsystem]]<br />
* [[Network UNIX/ARPANET Research]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=UsefulNeXTStepResearchNotes&diff=705UsefulNeXTStepResearchNotes2023-01-12T15:39:38Z<p>Kraaabs: Kraaabs moved page UsefulNeXTStepResearchNotes to Useful NeXTSTEP Research Notes: Cleaning page titles</p>
<hr />
<div>#REDIRECT [[Useful NeXTSTEP Research Notes]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=Useful_NeXTSTEP_Research_Notes&diff=704Useful NeXTSTEP Research Notes2023-01-12T15:39:38Z<p>Kraaabs: Kraaabs moved page UsefulNeXTStepResearchNotes to Useful NeXTSTEP Research Notes: Cleaning page titles</p>
<hr />
<div>'''vmlemon''' (''Today at 7:33 PM'')<br />
<div style="margin-left: 2em; line-height: calc(100% * 1.25);"><br />
[[File:Screenshot 2022-12-29 at 3.33.34 AM.png|590px|none]]<br />
<br />
I never thought I'd see that materialised<br />
[[File:Screenshot 2022-12-29 at 3.34.18 AM.png|590px|none]]<br />
<br />
Would be cooler, if I could actually breathe life into this stuff, and see it work, though<br />
<br />
Feels kinda weird, seeing a GCC-based compiler, for Windows, engineered by NeXT, too<br />
<br />
And, for whatever reason, they've nerfed the ability to get help for it, too<br />
[[File:Screenshot 2022-12-29 at 3.39.06 AM.png|590px|none]]<br />
<br />
Interesting tuple, there<br />
[[File:Screenshot 2022-12-29 at 3.39.29 AM.png|590px|none]]<br />
<br />
Feels really weird, seeing Windows-style paths, in a UNIX shell, and the tooling is pretty austere<br />
[[File:Screenshot 2022-12-29 at 3.40.47 AM.png|590px|none]]<br />
[[File:Screenshot 2022-12-29 at 3.41.07 AM.png|590px|none]]<br />
[[File:Screenshot 2022-12-29 at 3.41.27 AM.png|590px|none]]<br />
<br />
CygWin's version of GDB? That's unexpected<br />
[[File:Screenshot 2022-12-29 at 3.42.59 AM.png|590px|none]]<br />
<br />
That version of "df" seems kinda fucky, and cursed, too<br />
[[File:Screenshot 2022-12-29 at 3.44.34 AM.png|627px|none]]<br />
<br />
Dunno why it reports negative values<br />
<br />
Seems to ship its own, private copies of PostScript fonts, too<br />
<br />
</div><br />
'''suzuran''' (''Today at 7:47 PM'')<br />
<div style="margin-left: 2em; line-height: calc(100% * 1.25);"><br />
Because you rolled over 2^31?<br />
</div><br />
<br />
'''vmlemon''' (''Today at 7:49 PM'')<br />
<div style="margin-left: 2em; line-height: calc(100% * 1.25);"><br />
Probably - it's a 3GB filesystem, though, so well under the limit, for this version of NT<br />
</div><br />
<br />
'''suzuran''' (''Today at 7:50 PM'')<br />
<div style="margin-left: 2em; line-height: calc(100% * 1.25);"><br />
Yeah, 2GB is the 2^31 line.<br />
<br />
but knowing gnu stuff, they just used "int" and not "unsigned int"<br />
</div><br />
'''vmlemon''' (''Today at 7:50 PM'')<br />
<div style="margin-left: 2em; line-height: calc(100% * 1.25);"><br />
That makes sense<br />
<br />
The whole thing feels kinda kitbashed together, from disparate parts, and not everything seems to have source available for it<br />
<br />
Managed to pull the "NeXT" directory out, from the Windows disk image, though, so I can have a better look at it<br />
<br />
Seems to have more GNU stuff in it, than BSD stuff, somehow<br />
<br />
And, the WindowServer seems to paint PostScript output onto GDI canvases/contexts<br />
<br />
The Mach emulation stuff superficially seems less complex, than I expected, too - mostly just threading, and NT MailSlot communication<br />
<br />
They don't seem to use that much actual Mach code, in the headers - there's only NeXT copyright headers, on that stuff, but they mention snippets being taken from CMU Mach<br />
</div></div>Kraaabshttps://wiki.restless.systems/index.php?title=Autumnbreeze&diff=703Autumnbreeze2023-01-12T15:28:44Z<p>Kraaabs: Kraaabs moved page Autumnbreeze to User:AutumnBreeze: incorrect namespace</p>
<hr />
<div>#REDIRECT [[User:AutumnBreeze]]</div>Kraaabshttps://wiki.restless.systems/index.php?title=User:AutumnBreeze&diff=702User:AutumnBreeze2023-01-12T15:28:44Z<p>Kraaabs: Kraaabs moved page Autumnbreeze to User:AutumnBreeze: incorrect namespace</p>
<hr />
<div></div>Kraaabshttps://wiki.restless.systems/index.php?title=Discord_Moderation_Guide&diff=650Discord Moderation Guide2023-01-08T21:26:30Z<p>Kraaabs: /* Bans */</p>
<hr />
<div>[[Category:Discord]][[Category:Administration]]<br />
DisNCord uses a large set of moderation tools, and guidelines to ease the burden of server administration. The intent is to make moderation quick and easy to review, while still being able to handle large scale raids and other server events are handled. At the moment, this document only covers the Discord server, but should probably be expanded in time to cover YouTube, Fediverse, and this wiki.<br />
<br />
== Workflow ==<br />
<br />
== Moderator Permissions ==<br />
A quick rundown of who can do what is provided.<br />
<br />
=== Volunteers and Active Users ===<br />
At the moment, volunteers are a click role in #role-select, and there's no tracking for activity on Discord. However, it's been considered allowing these roles access to the warning command due to how activity on the server continues to grow.<br />
<br />
=== Channel/Project Manager ===<br />
'''Currently unused''', but in the past DisNCord had Project Managers, which were single channel moderators or category moderators. As moderator demand grows, its expected that this will come back.<br />
<br />
=== Half-Ops ===<br />
'''To Be Implemented:''' Half-ops are server moderators who have access to bot commands, but not the Discord built-in moderation commands. <br />
<br />
=== Server Moderator (Resident Madfolks) ===<br />
Server moderators hold up the rules and standards of DisNCord. They have access to the Discord moderation commands, and can pin and unpin messages as necessary, as well as access to all staff channels. Discord's built in moderation tools are not great for managing large servers, but are necessary for handling Raid Reporting, as handling message pins.<br />
<br />
Server Moderators may also delete individual messages from other users. Discord has a audit log, but in general, this should only done if a user refuses to, or after a disciplinary action is taken.<br />
<br />
=== Bot Wrangler ===<br />
Due to bots have unique sets of permissions, a dedicated bot wrangler role exists. Due to how Discord handles permissions, the Bot Wrangler role has full access to the base moderator commands, but may not be a moderator in and of themselves. '''This role is currently unused.'''<br />
<br />
=== Server Administrator ===<br />
Server Administrators have the Manage Server permission and are the top rank in the Discord, meaning they can add and remove ranks from all others.<br />
<br />
=== Founder/Owner ===<br />
This is NCommander, since they have the server crown.<br />
<br />
== Bots ==<br />
To aid staff, and moderations, as well as improve the general user experience, multiple bots have been added to DisNCord; here's an overview, combined with how they interact with moderation.<br />
<br />
=== YAGPDB.yxz ===<br />
'''Yet Another General Purpose Discord Bot''' or YAGPDB.yxz handles most of the basic moderation tasks on the server, as well as handling stream announcements, incident longing and more.<br />
<br />
At the moment, YAGPDB is responsible for the following<br />
* Streaming Announcements<br />
* Fun/Community items such as reputation, customs commands and more<br />
* Warnings<br />
* Flexible Timeouts/Mutes<br />
* Kick/Ban logging, and Notification DMs<br />
* Deleted Message logging<br />
<br />
While YAGPDB.yxz does offer a ticket system, its somewhat difficult to use, and requires bot commands, so we're not using it as such.<br />
<br />
=== Tickets ===<br />
<br />
=== SlashBot ===<br />
SlashBot handles mostly role selection, and is used in #role-select. It will likely be used in the future for premium configuration options and more. It might be replaced in the future with a simpler bot, or with YAGPDB replacing it.<br />
<br />
=== PluralKit ===<br />
<br />
== Actions ==<br />
Moderators on DisNCord can take various actions in regards to tickets and incidents. Actions, unless noted, should be done through either Tickets or YAGPDB as is necessary.<br />
<br />
=== Note ===<br />
Sometimes a ticket comes in, or a borderline action is witnessed, that warrants an official comment from a moderator, but doesn't reach the point that an actual warning should be raised.<br />
<br />
In these cases, a ticket should be opened by the moderator, and pull in any relevant offending users. If a moderator is acting on another ticket, the reporter should not be pulled in. Exposing a reporter of an issue opens them up to retaliation; a moderator speaking in a ticket is speaking on behalf of the server. Any relevant conversation should be held, and then the moderator should close ticket should be closed with a comment explaining why no action was taken. The log will be saved.<br />
<br />
These actions represent "we talked to someone about X", and will essentially be forgotten if the issue doesn't come up again. Moderators may request that a message be deleted in a note.<br />
<br />
=== Warnings ===<br />
Warnings are when an infraction of the server rules, or a violation of general good conduct occurs such as disruptive behavior. Essentially, its telling a user to stop before a stronger moderator action is taken. Warnings may be given publicly or privately via YAGPDB. In either case, YAGPDB will notify the user by DM that the warning was given.<br />
<br />
Warnings are given with the YAGPDB warn command, which is a slash command.<br />
<br />
<pre><br />
/warn user:<user> reason:<the text that will show up in the warning log><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
<br />
Warnings exist as an administrative function of the server, they do not have any penalty in and of themselves, but may influence further moderator decisions down the line. This is why warnings have to be documented. It's not uncommon that a user may need to have bad behavior corrected on more than one occasion. Documenting that warnings help the staff to understand where the rules need to be clarified, or be more stringent, as well as allowing for a way to handle disruptive behavior.<br />
<br />
Whomever files a warning must file a ticket that they have done so. In the ticket, they should include any relevant details on why they felt a warning was justified such as a chat link, YAGPDB.xyz log, or more. A warning may not necessarily cite a server rule. Citing the Discord TOS, or even a generalized reason such as inciting violence, are acceptable. In extreme cases, a warning may also be created if someone is considered at risk, and is requesting intervention from a senior staff member, or NCommander themselves.<br />
<br />
If necessary, moderators can capture a log from the bot on behalf of another user.<br />
<br />
Warnings may be appealed by a user by submitting a ticket.<br />
<br />
=== Timeouts/Mutes ===<br />
Muting a user means removing their ability to talk in all channels. Discord also offers a timeout feature, which does the same thing, but has very limited controls, and doesn't allow for exclusions. Once muted groups are properly setup, Discord's time-out feature should only be used if access to the ticket system needs to be silence (although then a ban may be warranted).<br />
<br />
Mutes are given with the YAGPDB warn command, which is a slash command.<br />
<br />
'''Discord has a built-in /timeout command, make sure you use the right one!'''<br />
<pre><br />
/timeout user:<user> reason:<the text that will show up in the warning log> duration:<how long><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
Timeouts represent the lowest level of mod action available, and can be for a few minutes to a few days, and essentially allows for someone to break up a conversation, or to drive through that an action is unacceptable in chat. Short duration timeouts (as in a few minutes to an hour) do not need to be justified; moderators are assumed to be responsible enough to use these as is. However, a timeout reason must be given via bot which will be delivered by DM to the user who was timed out, and reported in the #enforcement-action log.<br />
<br />
Long duration timeouts (a few hours to a few days) must be documented via a ticket, and a warning should also be applied. As with warnings, the moderator should open a ticket, provide any relevant documentation, and have another mod look it and close it.<br />
<br />
Mutes may be appealed. The muted role can still open tickets, and they have visibility on a special channel that shows that they have been muted. Like with warnings, moderators should remember that their ticket with original reasons may be referenced or even forwarded.<br />
<br />
=== Kicks ===<br />
DisNCord is a public server, so by its notion, kicking doesn't seem like it would accomplish much. However, a server kick removes all rules, and restores the mint "new user" icon that comes with it. It also requires the user go get the invite link again which represents efforts. In time, we may also add active and other ranks that are granted, which would cause a kick to reset.<br />
<br />
Kicks should be done YAGPDB kick command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /kick command, make sure you use the right one!'''<br />
<br />
<pre><br />
/Kick <User:Mention/ID> [Reason:Text]<br />
</pre><br />
<br />
Kicking should be used as a last resort to bans. Like warnings and mutes, kicks should be done through the bot and documented the same.<br />
<br />
Kicks, by their nature, can't be appealed; you just need to rejoin the server, and any new user filtering such as rules review must be redone. It also resets the join date.<br />
<br />
A user may request to be re-added to any lost roles by filing a ticket, to be granted at the discretion of another moderator who wasn't involved with the original decision.<br />
<br />
=== Bans ===<br />
Bans are the highest level of action a moderator can take, and can extend past Discord and include things like a wiki account, Patreon access or more, depending on severity. Bans are also used as a method to combat raids, and with combined with the Discord security level, provides key tools in keeping the server usable in times of strife and more.<br />
<br />
Bans are classified into anti-spam, and as a punishment for rules violations. Bans may be time limited, or may be permanent.<br />
<br />
Ban should be done YAGPDB ban command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /ban command, make sure you use the right one!'''<br />
<br />
<pre><br />
/ban <User:Mention/ID> <Reason:why was the ban needed> <duration> <ddays: how many messages to delete><br />
</pre><br />
<br />
Server moderators may use the Discord ban function if message deletion is needed to combat spam attacks due to it being easier to use than YAGPDB.xyz slash commands. The audit log must be filled out, and a note must be left in enforcement action that it was used.<br />
<br />
=== A Note On Message Deletion ===</div>Kraaabshttps://wiki.restless.systems/index.php?title=Discord_Moderation_Guide&diff=649Discord Moderation Guide2023-01-08T21:26:04Z<p>Kraaabs: /* Bans */</p>
<hr />
<div>[[Category:Discord]][[Category:Administration]]<br />
DisNCord uses a large set of moderation tools, and guidelines to ease the burden of server administration. The intent is to make moderation quick and easy to review, while still being able to handle large scale raids and other server events are handled. At the moment, this document only covers the Discord server, but should probably be expanded in time to cover YouTube, Fediverse, and this wiki.<br />
<br />
== Workflow ==<br />
<br />
== Moderator Permissions ==<br />
A quick rundown of who can do what is provided.<br />
<br />
=== Volunteers and Active Users ===<br />
At the moment, volunteers are a click role in #role-select, and there's no tracking for activity on Discord. However, it's been considered allowing these roles access to the warning command due to how activity on the server continues to grow.<br />
<br />
=== Channel/Project Manager ===<br />
'''Currently unused''', but in the past DisNCord had Project Managers, which were single channel moderators or category moderators. As moderator demand grows, its expected that this will come back.<br />
<br />
=== Half-Ops ===<br />
'''To Be Implemented:''' Half-ops are server moderators who have access to bot commands, but not the Discord built-in moderation commands. <br />
<br />
=== Server Moderator (Resident Madfolks) ===<br />
Server moderators hold up the rules and standards of DisNCord. They have access to the Discord moderation commands, and can pin and unpin messages as necessary, as well as access to all staff channels. Discord's built in moderation tools are not great for managing large servers, but are necessary for handling Raid Reporting, as handling message pins.<br />
<br />
Server Moderators may also delete individual messages from other users. Discord has a audit log, but in general, this should only done if a user refuses to, or after a disciplinary action is taken.<br />
<br />
=== Bot Wrangler ===<br />
Due to bots have unique sets of permissions, a dedicated bot wrangler role exists. Due to how Discord handles permissions, the Bot Wrangler role has full access to the base moderator commands, but may not be a moderator in and of themselves. '''This role is currently unused.'''<br />
<br />
=== Server Administrator ===<br />
Server Administrators have the Manage Server permission and are the top rank in the Discord, meaning they can add and remove ranks from all others.<br />
<br />
=== Founder/Owner ===<br />
This is NCommander, since they have the server crown.<br />
<br />
== Bots ==<br />
To aid staff, and moderations, as well as improve the general user experience, multiple bots have been added to DisNCord; here's an overview, combined with how they interact with moderation.<br />
<br />
=== YAGPDB.yxz ===<br />
'''Yet Another General Purpose Discord Bot''' or YAGPDB.yxz handles most of the basic moderation tasks on the server, as well as handling stream announcements, incident longing and more.<br />
<br />
At the moment, YAGPDB is responsible for the following<br />
* Streaming Announcements<br />
* Fun/Community items such as reputation, customs commands and more<br />
* Warnings<br />
* Flexible Timeouts/Mutes<br />
* Kick/Ban logging, and Notification DMs<br />
* Deleted Message logging<br />
<br />
While YAGPDB.yxz does offer a ticket system, its somewhat difficult to use, and requires bot commands, so we're not using it as such.<br />
<br />
=== Tickets ===<br />
<br />
=== SlashBot ===<br />
SlashBot handles mostly role selection, and is used in #role-select. It will likely be used in the future for premium configuration options and more. It might be replaced in the future with a simpler bot, or with YAGPDB replacing it.<br />
<br />
=== PluralKit ===<br />
<br />
== Actions ==<br />
Moderators on DisNCord can take various actions in regards to tickets and incidents. Actions, unless noted, should be done through either Tickets or YAGPDB as is necessary.<br />
<br />
=== Note ===<br />
Sometimes a ticket comes in, or a borderline action is witnessed, that warrants an official comment from a moderator, but doesn't reach the point that an actual warning should be raised.<br />
<br />
In these cases, a ticket should be opened by the moderator, and pull in any relevant offending users. If a moderator is acting on another ticket, the reporter should not be pulled in. Exposing a reporter of an issue opens them up to retaliation; a moderator speaking in a ticket is speaking on behalf of the server. Any relevant conversation should be held, and then the moderator should close ticket should be closed with a comment explaining why no action was taken. The log will be saved.<br />
<br />
These actions represent "we talked to someone about X", and will essentially be forgotten if the issue doesn't come up again. Moderators may request that a message be deleted in a note.<br />
<br />
=== Warnings ===<br />
Warnings are when an infraction of the server rules, or a violation of general good conduct occurs such as disruptive behavior. Essentially, its telling a user to stop before a stronger moderator action is taken. Warnings may be given publicly or privately via YAGPDB. In either case, YAGPDB will notify the user by DM that the warning was given.<br />
<br />
Warnings are given with the YAGPDB warn command, which is a slash command.<br />
<br />
<pre><br />
/warn user:<user> reason:<the text that will show up in the warning log><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
<br />
Warnings exist as an administrative function of the server, they do not have any penalty in and of themselves, but may influence further moderator decisions down the line. This is why warnings have to be documented. It's not uncommon that a user may need to have bad behavior corrected on more than one occasion. Documenting that warnings help the staff to understand where the rules need to be clarified, or be more stringent, as well as allowing for a way to handle disruptive behavior.<br />
<br />
Whomever files a warning must file a ticket that they have done so. In the ticket, they should include any relevant details on why they felt a warning was justified such as a chat link, YAGPDB.xyz log, or more. A warning may not necessarily cite a server rule. Citing the Discord TOS, or even a generalized reason such as inciting violence, are acceptable. In extreme cases, a warning may also be created if someone is considered at risk, and is requesting intervention from a senior staff member, or NCommander themselves.<br />
<br />
If necessary, moderators can capture a log from the bot on behalf of another user.<br />
<br />
Warnings may be appealed by a user by submitting a ticket.<br />
<br />
=== Timeouts/Mutes ===<br />
Muting a user means removing their ability to talk in all channels. Discord also offers a timeout feature, which does the same thing, but has very limited controls, and doesn't allow for exclusions. Once muted groups are properly setup, Discord's time-out feature should only be used if access to the ticket system needs to be silence (although then a ban may be warranted).<br />
<br />
Mutes are given with the YAGPDB warn command, which is a slash command.<br />
<br />
'''Discord has a built-in /timeout command, make sure you use the right one!'''<br />
<pre><br />
/timeout user:<user> reason:<the text that will show up in the warning log> duration:<how long><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
Timeouts represent the lowest level of mod action available, and can be for a few minutes to a few days, and essentially allows for someone to break up a conversation, or to drive through that an action is unacceptable in chat. Short duration timeouts (as in a few minutes to an hour) do not need to be justified; moderators are assumed to be responsible enough to use these as is. However, a timeout reason must be given via bot which will be delivered by DM to the user who was timed out, and reported in the #enforcement-action log.<br />
<br />
Long duration timeouts (a few hours to a few days) must be documented via a ticket, and a warning should also be applied. As with warnings, the moderator should open a ticket, provide any relevant documentation, and have another mod look it and close it.<br />
<br />
Mutes may be appealed. The muted role can still open tickets, and they have visibility on a special channel that shows that they have been muted. Like with warnings, moderators should remember that their ticket with original reasons may be referenced or even forwarded.<br />
<br />
=== Kicks ===<br />
DisNCord is a public server, so by its notion, kicking doesn't seem like it would accomplish much. However, a server kick removes all rules, and restores the mint "new user" icon that comes with it. It also requires the user go get the invite link again which represents efforts. In time, we may also add active and other ranks that are granted, which would cause a kick to reset.<br />
<br />
Kicks should be done YAGPDB kick command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /kick command, make sure you use the right one!'''<br />
<br />
<pre><br />
/Kick <User:Mention/ID> [Reason:Text]<br />
</pre><br />
<br />
Kicking should be used as a last resort to bans. Like warnings and mutes, kicks should be done through the bot and documented the same.<br />
<br />
Kicks, by their nature, can't be appealed; you just need to rejoin the server, and any new user filtering such as rules review must be redone. It also resets the join date.<br />
<br />
A user may request to be re-added to any lost roles by filing a ticket, to be granted at the discretion of another moderator who wasn't involved with the original decision.<br />
<br />
=== Bans ===<br />
Bans are the highest level of action a moderator can take, and can extend past Discord and include things like a wiki account, Patreon access or more, depending on severity. Bans are also used as a method to combat raids, and with combined with the Discord security level, provides key tools in keeping the server usable in times of strife and more.<br />
<br />
Bans are classified into anti-spam, and as a punishment for rules violations. Bans may be time limited, or may be permamement.<br />
<br />
Ban should be done YAGPDB ban command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /ban command, make sure you use the right one!'''<br />
<br />
<pre><br />
/ban <User:Mention/ID> <Reason:why was the ban needed> <duration> <ddays: how many messages to delete><br />
</pre><br />
<br />
Server moderators may use the Discord ban function if message deletion is needed to combat spam attacks due to it being easier to use than YAGPDB.xyz slash commands. The audit log must be filled out, and a note must be left in enforcement action that it was used.<br />
<br />
=== A Note On Message Deletion ===</div>Kraaabshttps://wiki.restless.systems/index.php?title=Discord_Moderation_Guide&diff=648Discord Moderation Guide2023-01-08T21:25:35Z<p>Kraaabs: /* Warnings */</p>
<hr />
<div>[[Category:Discord]][[Category:Administration]]<br />
DisNCord uses a large set of moderation tools, and guidelines to ease the burden of server administration. The intent is to make moderation quick and easy to review, while still being able to handle large scale raids and other server events are handled. At the moment, this document only covers the Discord server, but should probably be expanded in time to cover YouTube, Fediverse, and this wiki.<br />
<br />
== Workflow ==<br />
<br />
== Moderator Permissions ==<br />
A quick rundown of who can do what is provided.<br />
<br />
=== Volunteers and Active Users ===<br />
At the moment, volunteers are a click role in #role-select, and there's no tracking for activity on Discord. However, it's been considered allowing these roles access to the warning command due to how activity on the server continues to grow.<br />
<br />
=== Channel/Project Manager ===<br />
'''Currently unused''', but in the past DisNCord had Project Managers, which were single channel moderators or category moderators. As moderator demand grows, its expected that this will come back.<br />
<br />
=== Half-Ops ===<br />
'''To Be Implemented:''' Half-ops are server moderators who have access to bot commands, but not the Discord built-in moderation commands. <br />
<br />
=== Server Moderator (Resident Madfolks) ===<br />
Server moderators hold up the rules and standards of DisNCord. They have access to the Discord moderation commands, and can pin and unpin messages as necessary, as well as access to all staff channels. Discord's built in moderation tools are not great for managing large servers, but are necessary for handling Raid Reporting, as handling message pins.<br />
<br />
Server Moderators may also delete individual messages from other users. Discord has a audit log, but in general, this should only done if a user refuses to, or after a disciplinary action is taken.<br />
<br />
=== Bot Wrangler ===<br />
Due to bots have unique sets of permissions, a dedicated bot wrangler role exists. Due to how Discord handles permissions, the Bot Wrangler role has full access to the base moderator commands, but may not be a moderator in and of themselves. '''This role is currently unused.'''<br />
<br />
=== Server Administrator ===<br />
Server Administrators have the Manage Server permission and are the top rank in the Discord, meaning they can add and remove ranks from all others.<br />
<br />
=== Founder/Owner ===<br />
This is NCommander, since they have the server crown.<br />
<br />
== Bots ==<br />
To aid staff, and moderations, as well as improve the general user experience, multiple bots have been added to DisNCord; here's an overview, combined with how they interact with moderation.<br />
<br />
=== YAGPDB.yxz ===<br />
'''Yet Another General Purpose Discord Bot''' or YAGPDB.yxz handles most of the basic moderation tasks on the server, as well as handling stream announcements, incident longing and more.<br />
<br />
At the moment, YAGPDB is responsible for the following<br />
* Streaming Announcements<br />
* Fun/Community items such as reputation, customs commands and more<br />
* Warnings<br />
* Flexible Timeouts/Mutes<br />
* Kick/Ban logging, and Notification DMs<br />
* Deleted Message logging<br />
<br />
While YAGPDB.yxz does offer a ticket system, its somewhat difficult to use, and requires bot commands, so we're not using it as such.<br />
<br />
=== Tickets ===<br />
<br />
=== SlashBot ===<br />
SlashBot handles mostly role selection, and is used in #role-select. It will likely be used in the future for premium configuration options and more. It might be replaced in the future with a simpler bot, or with YAGPDB replacing it.<br />
<br />
=== PluralKit ===<br />
<br />
== Actions ==<br />
Moderators on DisNCord can take various actions in regards to tickets and incidents. Actions, unless noted, should be done through either Tickets or YAGPDB as is necessary.<br />
<br />
=== Note ===<br />
Sometimes a ticket comes in, or a borderline action is witnessed, that warrants an official comment from a moderator, but doesn't reach the point that an actual warning should be raised.<br />
<br />
In these cases, a ticket should be opened by the moderator, and pull in any relevant offending users. If a moderator is acting on another ticket, the reporter should not be pulled in. Exposing a reporter of an issue opens them up to retaliation; a moderator speaking in a ticket is speaking on behalf of the server. Any relevant conversation should be held, and then the moderator should close ticket should be closed with a comment explaining why no action was taken. The log will be saved.<br />
<br />
These actions represent "we talked to someone about X", and will essentially be forgotten if the issue doesn't come up again. Moderators may request that a message be deleted in a note.<br />
<br />
=== Warnings ===<br />
Warnings are when an infraction of the server rules, or a violation of general good conduct occurs such as disruptive behavior. Essentially, its telling a user to stop before a stronger moderator action is taken. Warnings may be given publicly or privately via YAGPDB. In either case, YAGPDB will notify the user by DM that the warning was given.<br />
<br />
Warnings are given with the YAGPDB warn command, which is a slash command.<br />
<br />
<pre><br />
/warn user:<user> reason:<the text that will show up in the warning log><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
<br />
Warnings exist as an administrative function of the server, they do not have any penalty in and of themselves, but may influence further moderator decisions down the line. This is why warnings have to be documented. It's not uncommon that a user may need to have bad behavior corrected on more than one occasion. Documenting that warnings help the staff to understand where the rules need to be clarified, or be more stringent, as well as allowing for a way to handle disruptive behavior.<br />
<br />
Whomever files a warning must file a ticket that they have done so. In the ticket, they should include any relevant details on why they felt a warning was justified such as a chat link, YAGPDB.xyz log, or more. A warning may not necessarily cite a server rule. Citing the Discord TOS, or even a generalized reason such as inciting violence, are acceptable. In extreme cases, a warning may also be created if someone is considered at risk, and is requesting intervention from a senior staff member, or NCommander themselves.<br />
<br />
If necessary, moderators can capture a log from the bot on behalf of another user.<br />
<br />
Warnings may be appealed by a user by submitting a ticket.<br />
<br />
=== Timeouts/Mutes ===<br />
Muting a user means removing their ability to talk in all channels. Discord also offers a timeout feature, which does the same thing, but has very limited controls, and doesn't allow for exclusions. Once muted groups are properly setup, Discord's time-out feature should only be used if access to the ticket system needs to be silence (although then a ban may be warranted).<br />
<br />
Mutes are given with the YAGPDB warn command, which is a slash command.<br />
<br />
'''Discord has a built-in /timeout command, make sure you use the right one!'''<br />
<pre><br />
/timeout user:<user> reason:<the text that will show up in the warning log> duration:<how long><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
Timeouts represent the lowest level of mod action available, and can be for a few minutes to a few days, and essentially allows for someone to break up a conversation, or to drive through that an action is unacceptable in chat. Short duration timeouts (as in a few minutes to an hour) do not need to be justified; moderators are assumed to be responsible enough to use these as is. However, a timeout reason must be given via bot which will be delivered by DM to the user who was timed out, and reported in the #enforcement-action log.<br />
<br />
Long duration timeouts (a few hours to a few days) must be documented via a ticket, and a warning should also be applied. As with warnings, the moderator should open a ticket, provide any relevant documentation, and have another mod look it and close it.<br />
<br />
Mutes may be appealed. The muted role can still open tickets, and they have visibility on a special channel that shows that they have been muted. Like with warnings, moderators should remember that their ticket with original reasons may be referenced or even forwarded.<br />
<br />
=== Kicks ===<br />
DisNCord is a public server, so by its notion, kicking doesn't seem like it would accomplish much. However, a server kick removes all rules, and restores the mint "new user" icon that comes with it. It also requires the user go get the invite link again which represents efforts. In time, we may also add active and other ranks that are granted, which would cause a kick to reset.<br />
<br />
Kicks should be done YAGPDB kick command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /kick command, make sure you use the right one!'''<br />
<br />
<pre><br />
/Kick <User:Mention/ID> [Reason:Text]<br />
</pre><br />
<br />
Kicking should be used as a last resort to bans. Like warnings and mutes, kicks should be done through the bot and documented the same.<br />
<br />
Kicks, by their nature, can't be appealed; you just need to rejoin the server, and any new user filtering such as rules review must be redone. It also resets the join date.<br />
<br />
A user may request to be re-added to any lost roles by filing a ticket, to be granted at the discretion of another moderator who wasn't involved with the original decision.<br />
<br />
=== Bans ===<br />
Bans are the highest level of action a moderator can take, and can extend past Discord and include things like a wiki account, Patreon access or more, depending on severity. Bans are also used as a method to combat raids, and with combined with the Discord security level, provides key tools in keeping the server usable in times of strife and more.<br />
<br />
Bans are classified into anti-spam, and as a punishment for rules violations. Bans may be time limited, or may be permamement.<br />
<br />
Ban should be done YAGPDB ban command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /ban command, make sure you use the right one!'''<br />
<br />
<pre><br />
/ban <User:Mention/ID> <Reason:why was the ban needed> <duration> <ddays: how many messages to delete><br />
</pre><br />
<br />
Server moderators may use the Discord ban function if message deletion is needed to combat spam attacks due to it being easier to use than YAGPDB.zxy slash commands. The audit log must be filled out, and a note must be left in enforcement action that it was used.<br />
=== A Note On Message Deletion ===</div>Kraaabshttps://wiki.restless.systems/index.php?title=Discord_Moderation_Guide&diff=647Discord Moderation Guide2023-01-08T21:25:15Z<p>Kraaabs: /* Server Administrator */</p>
<hr />
<div>[[Category:Discord]][[Category:Administration]]<br />
DisNCord uses a large set of moderation tools, and guidelines to ease the burden of server administration. The intent is to make moderation quick and easy to review, while still being able to handle large scale raids and other server events are handled. At the moment, this document only covers the Discord server, but should probably be expanded in time to cover YouTube, Fediverse, and this wiki.<br />
<br />
== Workflow ==<br />
<br />
== Moderator Permissions ==<br />
A quick rundown of who can do what is provided.<br />
<br />
=== Volunteers and Active Users ===<br />
At the moment, volunteers are a click role in #role-select, and there's no tracking for activity on Discord. However, it's been considered allowing these roles access to the warning command due to how activity on the server continues to grow.<br />
<br />
=== Channel/Project Manager ===<br />
'''Currently unused''', but in the past DisNCord had Project Managers, which were single channel moderators or category moderators. As moderator demand grows, its expected that this will come back.<br />
<br />
=== Half-Ops ===<br />
'''To Be Implemented:''' Half-ops are server moderators who have access to bot commands, but not the Discord built-in moderation commands. <br />
<br />
=== Server Moderator (Resident Madfolks) ===<br />
Server moderators hold up the rules and standards of DisNCord. They have access to the Discord moderation commands, and can pin and unpin messages as necessary, as well as access to all staff channels. Discord's built in moderation tools are not great for managing large servers, but are necessary for handling Raid Reporting, as handling message pins.<br />
<br />
Server Moderators may also delete individual messages from other users. Discord has a audit log, but in general, this should only done if a user refuses to, or after a disciplinary action is taken.<br />
<br />
=== Bot Wrangler ===<br />
Due to bots have unique sets of permissions, a dedicated bot wrangler role exists. Due to how Discord handles permissions, the Bot Wrangler role has full access to the base moderator commands, but may not be a moderator in and of themselves. '''This role is currently unused.'''<br />
<br />
=== Server Administrator ===<br />
Server Administrators have the Manage Server permission and are the top rank in the Discord, meaning they can add and remove ranks from all others.<br />
<br />
=== Founder/Owner ===<br />
This is NCommander, since they have the server crown.<br />
<br />
== Bots ==<br />
To aid staff, and moderations, as well as improve the general user experience, multiple bots have been added to DisNCord; here's an overview, combined with how they interact with moderation.<br />
<br />
=== YAGPDB.yxz ===<br />
'''Yet Another General Purpose Discord Bot''' or YAGPDB.yxz handles most of the basic moderation tasks on the server, as well as handling stream announcements, incident longing and more.<br />
<br />
At the moment, YAGPDB is responsible for the following<br />
* Streaming Announcements<br />
* Fun/Community items such as reputation, customs commands and more<br />
* Warnings<br />
* Flexible Timeouts/Mutes<br />
* Kick/Ban logging, and Notification DMs<br />
* Deleted Message logging<br />
<br />
While YAGPDB.yxz does offer a ticket system, its somewhat difficult to use, and requires bot commands, so we're not using it as such.<br />
<br />
=== Tickets ===<br />
<br />
=== SlashBot ===<br />
SlashBot handles mostly role selection, and is used in #role-select. It will likely be used in the future for premium configuration options and more. It might be replaced in the future with a simpler bot, or with YAGPDB replacing it.<br />
<br />
=== PluralKit ===<br />
<br />
== Actions ==<br />
Moderators on DisNCord can take various actions in regards to tickets and incidents. Actions, unless noted, should be done through either Tickets or YAGPDB as is necessary.<br />
<br />
=== Note ===<br />
Sometimes a ticket comes in, or a borderline action is witnessed, that warrants an official comment from a moderator, but doesn't reach the point that an actual warning should be raised.<br />
<br />
In these cases, a ticket should be opened by the moderator, and pull in any relevant offending users. If a moderator is acting on another ticket, the reporter should not be pulled in. Exposing a reporter of an issue opens them up to retaliation; a moderator speaking in a ticket is speaking on behalf of the server. Any relevant conversation should be held, and then the moderator should close ticket should be closed with a comment explaining why no action was taken. The log will be saved.<br />
<br />
These actions represent "we talked to someone about X", and will essentially be forgotten if the issue doesn't come up again. Moderators may request that a message be deleted in a note.<br />
<br />
=== Warnings ===<br />
Warnings are when an infraction of the server rules, or a violation of general good conduct occurs such as disruptive behavior. Essentially, its telling a user to stop before a stronger moderator action is taken. Warnings may be given publicly or privately via YAGPDB. In either case, YAGPDB will notify the user by DM that the warning was given.<br />
<br />
Warnings are given with the YAGPDB warn command, which is a slash command.<br />
<br />
<pre><br />
/warn user:<user> reason:<the text that will show up in the warning log><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
<br />
Warnings exist as an administrative function of the server, they do not have any penalty in and of themselves, but may influence further moderator decisions down the line. This is why warnings have to be documented. It's not uncommon that a user may need to have bad behavior corrected on more than one occasion. Documenting that warnings help the staff to understand where the rules need to be clarified, or be more stringent, as well as allowing for a way to handle disruptive behavior.<br />
<br />
Whomever files a warning must file a ticket that they have done so. In the ticket, they should include any relevant details on why they felt a warning was justified such as a chat link, YAGDB.zxy log, or more. A warning may not necessarily cite a server rule. Citing the Discord TOS, or even a generalized reason such as inciting violence, are acceptable. In extreme cases, a warning may also be created if someone is considered at risk, and is requesting intervention from a senior staff member, or NCommander themselves.<br />
<br />
If necessary, moderators can capture a log from the bot on behalf of another user.<br />
<br />
Warnings may be appealed by a user by submitting a ticket.<br />
<br />
=== Timeouts/Mutes ===<br />
Muting a user means removing their ability to talk in all channels. Discord also offers a timeout feature, which does the same thing, but has very limited controls, and doesn't allow for exclusions. Once muted groups are properly setup, Discord's time-out feature should only be used if access to the ticket system needs to be silence (although then a ban may be warranted).<br />
<br />
Mutes are given with the YAGPDB warn command, which is a slash command.<br />
<br />
'''Discord has a built-in /timeout command, make sure you use the right one!'''<br />
<pre><br />
/timeout user:<user> reason:<the text that will show up in the warning log> duration:<how long><br />
</pre><br />
<br />
[https://docs.yagpdb.xyz/commands/all-commands Full syntax] is available on the YAGPDB documentation page.<br />
<br />
Timeouts represent the lowest level of mod action available, and can be for a few minutes to a few days, and essentially allows for someone to break up a conversation, or to drive through that an action is unacceptable in chat. Short duration timeouts (as in a few minutes to an hour) do not need to be justified; moderators are assumed to be responsible enough to use these as is. However, a timeout reason must be given via bot which will be delivered by DM to the user who was timed out, and reported in the #enforcement-action log.<br />
<br />
Long duration timeouts (a few hours to a few days) must be documented via a ticket, and a warning should also be applied. As with warnings, the moderator should open a ticket, provide any relevant documentation, and have another mod look it and close it.<br />
<br />
Mutes may be appealed. The muted role can still open tickets, and they have visibility on a special channel that shows that they have been muted. Like with warnings, moderators should remember that their ticket with original reasons may be referenced or even forwarded.<br />
<br />
=== Kicks ===<br />
DisNCord is a public server, so by its notion, kicking doesn't seem like it would accomplish much. However, a server kick removes all rules, and restores the mint "new user" icon that comes with it. It also requires the user go get the invite link again which represents efforts. In time, we may also add active and other ranks that are granted, which would cause a kick to reset.<br />
<br />
Kicks should be done YAGPDB kick command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /kick command, make sure you use the right one!'''<br />
<br />
<pre><br />
/Kick <User:Mention/ID> [Reason:Text]<br />
</pre><br />
<br />
Kicking should be used as a last resort to bans. Like warnings and mutes, kicks should be done through the bot and documented the same.<br />
<br />
Kicks, by their nature, can't be appealed; you just need to rejoin the server, and any new user filtering such as rules review must be redone. It also resets the join date.<br />
<br />
A user may request to be re-added to any lost roles by filing a ticket, to be granted at the discretion of another moderator who wasn't involved with the original decision.<br />
<br />
=== Bans ===<br />
Bans are the highest level of action a moderator can take, and can extend past Discord and include things like a wiki account, Patreon access or more, depending on severity. Bans are also used as a method to combat raids, and with combined with the Discord security level, provides key tools in keeping the server usable in times of strife and more.<br />
<br />
Bans are classified into anti-spam, and as a punishment for rules violations. Bans may be time limited, or may be permamement.<br />
<br />
Ban should be done YAGPDB ban command, which is a slash command.<br />
<br />
'''Discord (and Slashbot) has a built-in /ban command, make sure you use the right one!'''<br />
<br />
<pre><br />
/ban <User:Mention/ID> <Reason:why was the ban needed> <duration> <ddays: how many messages to delete><br />
</pre><br />
<br />
Server moderators may use the Discord ban function if message deletion is needed to combat spam attacks due to it being easier to use than YAGPDB.zxy slash commands. The audit log must be filled out, and a note must be left in enforcement action that it was used.<br />
=== A Note On Message Deletion ===</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=565Project:Discord Bot Improvements2023-01-03T15:48:42Z<p>Kraaabs: </p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# <del>See about using user permissions for the bot, rather than any moderator permissions</del> '''DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)'''<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# <del>Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)</del> '''DONE! (although I'm on the fence about including them in the JSON output. Boy howdy, base64 can get LARGE)'''<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard -- but it's discord integrated<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
* UX is somewhat inconsistent and awkward<br />
* Piles up closed tickets as channels with no real archival<br />
* GDPR clause just says "contact us" with no other info<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
* Very polished interface<br />
* Deletes ticket channels when tickets are closed, but archives them in a thread for later viewing<br />
* Allows for the creation of custom forms and panels for ticket creation!<br />
==== Cons ====<br />
* Again, some features are paywalled (but nothing super essential...)<br />
* GDPR is handled through a discord server, which is... odd<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=549Project:Discord Bot Improvements2023-01-03T00:59:46Z<p>Kraaabs: /* Raconteur TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# <del>See about using user permissions for the bot, rather than any moderator permissions</del> '''DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)'''<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# <del>Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)</del> '''DONE! (although I'm on the fence about including them in the JSON output. Boy howdy, base64 can get LARGE)'''<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=548Project:Discord Bot Improvements2023-01-03T00:35:49Z<p>Kraaabs: /* Raconteur TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# <del>See about using user permissions for the bot, rather than any moderator permissions</del> '''DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)'''<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=547Project:Discord Bot Improvements2023-01-03T00:33:50Z<p>Kraaabs: this looks way better bold ~Sarah</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> '''DONE! (sorta. docs aren't there yet)'''<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> '''DONE! (at least to the level of the proactive logging)'''<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=546Project:Discord Bot Improvements2023-01-03T00:33:09Z<p>Kraaabs: add repository link for Raconteur and update the TODO ~Sarah</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
[https://gitlab.com/sarahcrowle/raconteur Raconteur repository on GitLab]<br />
<br />
=== Raconteur TODO ===<br />
<br />
# <del>Better document the code, and open the repository up to the public</del> DONE! (sorta. docs aren't there yet)<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# <del>Flesh out retroactive logging (in addition to the proactive logging already implemented)</del> DONE! (at least to the level of the proactive logging)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=545Project:Discord Bot Improvements2023-01-02T17:58:12Z<p>Kraaabs: /* TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
### Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=544Project:Discord Bot Improvements2023-01-02T17:55:37Z<p>Kraaabs: /* TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking<br />
# Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=543Project:Discord Bot Improvements2023-01-02T17:50:29Z<p>Kraaabs: /* TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
### Although, we don't actually need to self host those. In fact, I don't think we ''can'' (duh. coffee finally kicked in I guess) <br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=542Project:Discord Bot Improvements2023-01-02T17:47:47Z<p>Kraaabs: /* TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
## Actually, podman could work too, and it's a bit simpler... <br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)<br />
## Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=541Project:Discord Bot Improvements2023-01-02T16:51:56Z<p>Kraaabs: /* Raconteur TODO */</p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://doc.wikimedia.org/pywikibot/stable/index.html it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)</div>Kraaabshttps://wiki.restless.systems/index.php?title=Project:Discord_Bot_Improvements&diff=540Project:Discord Bot Improvements2023-01-02T16:42:54Z<p>Kraaabs: </p>
<hr />
<div>This is a general TODO area for improvements to the bot situation on DisNCord. Contact [[User:Kraaabs]] (Krabs#0571 on Discord) with comments/concerns/suggestions!<br />
<br />
== Better Discord logging ==<br />
<br />
As it stands, the wiki discussion logs (such as [[Lotus Notes and Taligent Shenanigans Log]] or [[SoylentNews History Log]]) are manually copied and pasted before being either [https://gitlab.com/sarahcrowle/raccoon.rb run through a script] to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:<br />
<br />
# Things are easily missed<br />
## Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.<br />
# Manual labour<br />
## The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.<br />
## Logs with images (such as [[Lotus Notes and Taligent Shenanigans Log]]) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.<br />
# Formatting<br />
## Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.<br />
<br />
[[User:Kraaabs]] has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.<br />
<br />
=== Raconteur TODO ===<br />
<br />
# Better document the code, and open the repository up to the public<br />
# See about using user permissions for the bot, rather than any moderator permissions<br />
# Flesh out retroactive logging (in addition to the proactive logging already implemented)<br />
# Grab embeds for messages as well (maybe embed them in the JSON log format as base64?)<br />
# Containerize it! (see below)<br />
# MediaWiki companion bot to upload images/automatically create pages ([https://github.com/barrust/mediawiki it seems there are mature Python bindings for the MediaWiki API])<br />
# Whatever else I forgot (I'm sure I'll add more as I go)<br />
<br />
== Modmail/Ticketing ==<br />
<br />
Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with [[User:NCommander]] having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact [[User:Kraaabs]] (Krabs#0571 on Discord) with your thoughts!<br />
<br />
Current proposed candidates:<br />
<br />
=== [https://github.com/ihaveamac/discord-mod-mail discord-mod-mail] ===<br />
==== Pros ====<br />
* ''Extremely'' simple codebase<br />
* Sirocyl has experience with it<br />
* Already dockerized<br />
* Looks easily hackable if needed<br />
==== Cons ====<br />
* Uses old-style prefixed bot commands (not ''necessarily'' a con per-se)<br />
* No formal role-locking -- relies on channel visibility<br />
<br />
=== [https://tickettool.xyz Ticket Tool] ===<br />
==== Pros ====<br />
* Appears very robust feature-wise<br />
* Comes with a handy dashboard<br />
* Seemingly scales well<br />
==== Cons ====<br />
* The free version is rate-limited (although I don't think we'll hit the limit)<br />
* Features such as DM support are locked behind a paywall<br />
<br />
=== [https://ticketsbot.net Tickets] ===<br />
==== Pros ====<br />
* Similar feature set to Ticket Tool<br />
* Allows multiple support teams<br />
* Similar to Ticket Tool, used on many many servers already<br />
==== Cons ====<br />
* Again, some features are paywalled<br />
<br />
== Bot Infrastructure == <br />
<br />
The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.<br />
<br />
=== TODO ===<br />
<br />
# Do we need a separate VPS for bots? Or will we host on the wiki infra?<br />
# Are all the bots we want to host Dockerized already? Or do we need to make our own containers?<br />
# How will we manage the containers? Manually, or with something like K8s?<br />
# If we want to do auto-updates (we probably do) how will we accomplish this? <br />
## [[User:NCommander]] had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...<br />
# For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)</div>Kraaabs