DIY 12V DC Power Supply

2025-01-23T00:00:00+00:00

Let’s talk about our journey of creating something from scratch (almost?) for our Electronics I</strong> final project. It wasn’t groundbreaking like a full-blown multi-featured DC power supply, but it was a fulfilling learning experience.</p>

Spoiler alert: mistakes were made, lessons were learned, and yes, we had fun.</em></p> </span>

</span></a> Design and Calculations</h2>
It began with brainstorming and sketching out ideas. This was our chance to put all the knowledge from our lectures to the test, from diode operating regions to voltage regulation. It was exciting but also a bit daunting.</p>
The first decision was our power supply's specifications. We aimed for a 12V output</strong>, a solid middle ground between complexity and functionality. Plus, the 5V option was already claimed by another group. For rectification, we chose a full-wave bridge rectifier</strong> due to its efficiency compared to the half-wave alternative.</p>
Calculations? Oh yes, there were plenty! Every components had to line up on paper before moving to reality.</p>
We started at the output, aiming for a stable 12V. To achieve this, we selected the LM7812 voltage regulator</strong>. It was an obvious choice: simple, reliable, and readily available. With an input range of 14.5 to 27V, it could easily provide the 12V we needed.</p>
Since the LM7812 can handle a maximum input voltage of 27V, a 12-0-12V transformer would be perfect. However, only a 6-0-6V transformer</strong> was available, so we had to make do with that. Regarding with the diode, we used 1N4007</strong> diodes as it is readily available and can handle our desired specifications.</p>
Assuming the provided input voltage for the regulator is 15.5V, which is also the output of the rectifier $ V_{\text{p(rec)}} $, the output voltage of the secondary side of the transformer $ V_{\text{p(sec)}} $ must be:</p>
$$ V_{\text{p(sec)}} = V_{\text{p(rec)}} + 1.4V = 15.5V + 1.4V = 16.9V_{\text{pk}} $$</p>
Note: The 1.4V was to account for the voltage drop across the diodes.</em></p>
or in RMS,</p>
$$ \frac{16.9V_{\text{pk}}}{\sqrt{2}} = 11.95V_{\text{rms}} $$</p>
This is perfect four our 6-0-6V transformer maximum output voltage of 12V in RMS.</p>
Using the formula for ripple factor,</p>
$$ r = \frac{V_{\text{r(pp)}}}{V_{\text{dc}}} $$</p>
$$ V_{\text{r(pp)}} = r \times V_{\text{dc}} $$</p>
we can determine the value of the filter capacitor, given a ripple factor $ r $ of 3% or 0.03, and output DC voltage $ V_{\text{dc}} $ of 12V.</p>
$$ V_{\text{r(pp)}} = \frac{V_{\text{p(rect)}}}{f \times R_\text{L} \times C} $$</p>
$$ C = \frac{V_{\text{p(rect)}}}{f \times R_\text{L} \times V_{\text{r(pp)}}} = \frac{V_{\text{p(rect)}}}{f \times R_\text{L} \times r \times V_{\text{dc}}} $$</p>
We also know that a typical frequency of the AC input is 60Hz and we have to multiply it by 2 to get the frequency of the full-wave rectified output.</p>
$$ f = 2 \times 60Hz = 120Hz $$</p>
Also, given the maximum load current of 50mA, we can calculate the assumed load resistance.</p>
$$ R_{\text{L}} = \frac{V_{\text{dc}}}{I_{\text{L}}} = \frac{12V}{50mA} = 240\Omega $$</p>
Substituting the values,</p>
$$ C = \frac{15.5V}{120Hz \times 240\Omega \times 0.03 \times 12V} = 1495 \mu F \approx 1.5 mF $$</p>
Here is the final schematic diagram of our design based on the calculations:</p>
</p>
</span></a> PCB Design, Etching and Soldering</h3>
For the PCB design, we used EasyEDA. It was our first time using it, but it was surprisingly intuitive. We just had first to recreate the schematic diagram, then layout the components and traces.</p>
</p>
Tracing the components on the PCB was a bit tricky, but we managed to get it done. It is like playing connect-the-dots, except no overlapping lines are allowed since we only had a single-layer PCB.</p>
</p>
At the end, it was satisfying to see the final design.</p>
</p>
We had to print it on a sticker paper, transfer it to the copper board, cut it, drill it, etch it, and solder the components.</p>
</p>
Did we also mention that we soldered the regulator in reverse for the first time? Oops.</p>
</span></a> Line Regulation Via Varying Input Voltage</h3>
For the first table, we vary the input voltage, and we measured the input voltage, the transformer output, the filter output, the regulator output, and the percent voltage regulation.</p>
Trial No.</th> Input Voltage ($ V_{\text{rms}} $)</th> Transformer Output ($ V_{\text{rms}} $)</th> Filter Output ($ V_{\text{DC}} $)</th> Regulator Output ($ V_{\text{DC}} $)</th> % Voltage Regulation</th></tr></thead>

1</td> 213</td> 12.1</td> 13.58</td> 11.97</td> 5</td></tr>
2</td> 214</td> 11.2</td> 13.82</td> 11.92</td> 5</td></tr>
3</td> 215</td> 10.7</td> 13.73</td> 12.03</td> 10</td></tr>
4</td> 216</td> 11.5</td> 13.80</td> 11.93</td> 10</td></tr>
5</td> 217</td> 10.8</td> 13.26</td> 12.01</td> 9</td></tr>
6</td> 218</td> 11.0</td> 13.59</td> 11.92</td> 9</td></tr>
7</td> 220</td> 11.3</td> 13.74</td> 11.92</td> 2</td></tr>
8</td> 222</td> 12.5</td> 13.61</td> 11.96</td> 2</td></tr>
9</td> 224</td> 12.3</td> 13.57</td> 11.93</td> 10</td></tr>
10</td> 226</td> 11.9</td> 13.88</td> 11.94</td> 10</td></tr>
Average</td> -</td> 11.53</td> 13.67</td> 11.953</td> 5.5</td></tr> </tbody></table>
Note: The load resistor is a 22Ω resistor.</em></p>
</p>
</span></a> Load Regulation Via Varying Load Resistance</h3>
For the second table, we vary the load resistance, and we measured the input voltage, the transformer output, the filter output, the regulator output, and the percent voltage regulation.</p>
Trial No.</th> Load Resistance ($ \Omega $)</th> Transformer Output ($ V_{\text{rms}} $)</th> Filter Output ($ V_{\text{DC}} $)</th> Regulator Output ($ V_{\text{FL(DC)}} $)</th> % Voltage Regulation</th></tr></thead>

1</td> 220</td> 10.6</td> 11.96</td> 10.22</td> 16.4385</td></tr>
2</td> 500</td> 10.7</td> 12.83</td> 11.43</td> 4.1120</td></tr>
3</td> 1k</td> 11.1</td> 13.05</td> 11.46</td> 3.8394</td></tr>
4</td> 2k</td> 11.1</td> 13.06</td> 11.48</td> 3.6585</td></tr>
5</td> 5k</td> 10.6</td> 13.20</td> 11.49</td> 3.5683</td></tr>
6</td> 6k</td> 10.9</td> 13.26</td> 11.78</td> 1.0187</td></tr>
7</td> 10k</td> 11.2</td> 13.39</td> 11.85</td> 0.4219</td></tr>
8</td> 11k</td> 11.3</td> 13.91</td> 11.87</td> 0.2527</td></tr>
9</td> 20k</td> 11.3</td> 13.53</td> 11.89</td> 0.0841</td></tr>
10</td> 22k</td> 11.1</td> 13.27</td> 11.90</td> 0</td></tr>
Average</td> -</td> 10.99</td> 13.15</td> 11.54</td> 3.3394</td></tr> </tbody></table>
Note: The primary voltage applied to the transformer was 220V in RMS. The $ V_{\text{NL(DC)}} $ used in computing the % voltage regulation is 11.9 V.</em></p>
</p>
</span></a> Data Interpretation</h3>
Looking at the tables, the LM7812 did a great job keeping the output mostly steady at 12V, even when we threw in some wild input voltage swings. That said, when the load resistance became too low, it struggled a bit, showing the limits of our trusty (but modest) 6-0-6V transformer. On the other hand, our filtering capacitors kept the ripples under control and gave us a smooth DC output.</p>
</span></a> Closing Words</h2>
This DC power supply project was a fantastic learning experience; it brought classroom concepts to life and gave us hands-on insight into circuit design and testing. While it performed well for what it is, it’s important to note that this design isn’t meant for serious, high-stakes applications. Think of it more as a stepping stone than a professional-grade project.</p>
Overall, we learned a lot about troubleshooting, design limitations, and real-world performance. With a bit more fine-tuning, this could even inspire more advanced builds down the line. For now, it’s a win for learning and the satisfaction of making something work (mostly) as planned!</p>
Special thanks to our professor for guiding us and to my amazing groupmates—Roneline, Rhaniel, Peejay, Aaron, and Rohn—for making this experience enjoyable and productive (ask them?).</p>
If you have any questions or feedback, feel free to leave a comment below. We’d love to hear your thoughts or critiques. Until next time, happy tinkering!</p>

Introducing Delineate!

2024-09-23T12:29:00.001+08:00

Delineate provides facilities to edit and draw graphs specified in the DOT language</a>. It is designed to be a simple and intuitive tool for creating and editing graphs, with a focus on the user experience.</p> </blockquote> </span>
As mentioned above, Delineate, previously named Dagger, is a new app to view and edit DOT graphs. It is like KGraphViewer</a>, but with the ability to edit the graph and is built with LibAdwaita, which makes it more at home on GNOME. There is also another app called GraphUI</a>, but it is currently unmaintained and designed for Elementary OS.</p>
</span></a> Features</h2>
One of the main reasons I developed Delineate is for debugging GStreamer pipeline dumps. I use it extensively to visualize the pipeline, inspect the elements, and analyze the negotiations between them.</p>
</p>
It is also useful for visualizing connections on the message bus, offering an alternative perspective to tools like Bustle.</p>
</p>
Another use case I discovered from Bilal is visualizing the Pipewire graph from the `pw-dot</code> command.</p>`
`</p>`
`The app also supports changing the layout engine on the fly, which is useful for tweaking the graph to make it more readable depending on the use case.</p>`
`</p>`
`Also, thanks to the library behind the app,` `d3-graphviz</a>, it supports animations, which can be less jarring when modifying the graph.</p>`
`</p>`
`Finally, you can export the graph to a PNG, SVG, or JPG image.</p>`
`</p>`
</span></a> Getting Delineate</h2> Delineate is available on Flathub</a>. You can install it from there, and since all of our code is open-source and can be freely modified and distributed according to the license, you can also download</a> and build it from source.</p> </span></a> Future Plans</h2> Since this is the first release, there are many features I would like to add in the future. Some of the features I am considering are:</p> More interactive editing and viewing features, such as selective highlighting of elements when searching.</li> Support for other graph formats, such as Mermaid</a>.</li> Bird's eye view for large graphs.</li> More useful text editing features, such as auto-completion, color picker, and more.</li> </ul> </span></a> Closing Words</h2> Before I end this post, I would like to thank Brage Fuglseth for the new name, Delineate, and the beautiful icon design.</p> </p> I hope you find Delineate as useful as I do. If you have any feedback or suggestions, feel free to open a discussion or issue on the GitHub repository</a>. Enjoy the release!</p>
Kooha 2.3 Released! 2024-03-24T12:29:00.001+08:00 Kooha</a> is a simple screen recorder for Linux with a minimal interface. You can simply click the record button without having to configure a bunch of settings.</p> </blockquote> While we strive to keep Kooha simple, we also want to make it better. This release, composed of over 300 commits</a>, is focused on quality-of-life improvements and bug fixes.</p> </span> This release includes a refined interface, improved area selection, more informative notifications, and other changes. Read on to learn more about the new features and improvements.</p> </span></a> New Features and Improvements</h2> </span></a> Refined Interface</h3> The main screen now has a more polished look. It now shows the selected format and FPS. This makes it easier to see the current settings at a glance, without having to open the settings window.</p> </p> Other than that, progress is now shown when flushing the recording. This gives a better indication when encoding or saving is taking longer than expected.</p> </p> Furthermore, the preferences window is also improved. It is now more descriptive and selecting FPS is now easier with a dropdown menu.</p> </p> </span></a> Improved Area Selection</h3> The area selection window is now resizable. You can now resize the window to fit your screen better. Additionally, the previously selected area is now remembered across sessions. This means that if you close Kooha and open it again, the area you selected will be remembered. Other improvements include improved focus handling, sizing fixes, better performance, and a new style.</p> </p> </span></a> More Informative Notifications</h3> Record-done notifications now show the duration and size of the recorded video. This is inspired by GNOME Shell screencast notifications.</p> </p> Moreover, the notification actions now work even when the application is closed.</p> </span></a> Other Changes</h3> Besides the mentioned features, this release also includes:</p> Logout and idle are now inhibited while recording.</li> The audio no longer stutters and gets corrupted when recording for a long time.</li> The audio is now recorded in stereo instead of mono when possible.</li> The recordings are no longer deleted when flushing is canceled.</li> Incorrect output video orientation on certain compositors is now fixed.</li> Performance and stability are improved.</li> </ul> </span></a> Getting Kooha 2.3</h2> Kooha is available on Flathub</a>. You can install it from there, and since all of our code is open-source and can be freely modified and distributed according to the license, you can also download</a> and build it from source.</p> </span></a> Closing Words</h2> Thanks to everyone who has supported Kooha, be it through donations, bug reports, translations, or just using it. Your support is what keeps this project going. Enjoy the new release!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Final Overview) 2023-08-28T12:29:00.001+08:00 Over the summer, for 12 weeks, I worked on rewriting Bustle in Rust and GTK 4 as part of the Google Summer of Code (GSoC) 2023 program. This post is an overview of the work done and the future plans for the project.</p> </span></span></a> About Bustle</h2> Bustle</a> is a graphical application used to analyze D-Bus</a> activities. It uses sequence diagrams to present signal emissions and method calls messages.</p> </p> Bustle represents these messages using a row-based layout. Each row is dedicated to displaying the following information: the elapsed time since the first message, the message path, and the member, which could be the name of the emitted signal or invoked method. On the other hand, individual columns correspond to distinct D-Bus services. Bustle draws arrows that transverse these columns to visualize the communication between services, while arcs represent method invocations and returns. This visual paradigm is valuable as, for instance, it can be used to see which services a D-Bus application talks to and how often, which can be handy in debugging, enhancing security, and optimizing performance within the application.</p> </span></a> Project Goal</h2> The ultimate goal of this project is to port Bustle to GTK 4 and rewrite it in Rust. Although the current implementation of Bustle in Haskell and GTK 3 is functional, there are compelling reasons to consider a rewrite in Rust. This includes enabling the tool to take advantage of a range of ergonomic libraries, including zbus</a>, gtk4-rs</a>, and pcap-file</a>, that would ease the burden in maintenance. Furthermore, the growing Rust community and the availability of the Rust SDK in Flathub</a> would make the tool more accessible to potential contributors and simpler to distribute to users.</p> Porting the tool to GTK 4</a>, on the other hand, would offer several benefits, such as access to newer and more performant widgets and drawing APIs like GtkListView</code> and GskPath</code>. This would allow Bustle to benefit from the latest developments in the platform and remain current with evolving standards.</p> Altogether, a rewrite of Bustle in Rust and GTK 4 would provide advantages that can enhance the tool's functionality, maintainability, longevity, accessibility, and possibly efficiency.</p> </span></a> Work Done</h2> Most of the tasks in the original proposal have been completed. This includes having an initial MVP, porting GDBus usage to zbus, implementing file loading and saving, completing the recording functionality, and porting the UI, which comprises the diagram, details view, and services filter, to GTK 4.</p> For more details on the work done, there are also bi-weekly updates</a> on my blog.</p> </span></a> Snapshots</h3> </span></a> Diagram and Details View</h4> </p> </span></a> Recording and Services Filter</h4> </p> </span></a> Code Merged</h2> These are the summary of code that has been merged during the GSoC period.</p> </span></a> Bustle</h3> Most of the work done is in the Bustle GNOME GitLab repository</a>, where the following pull requests have been merged:</p> Basic parsing and diagram implementation</a></li> Port to zbus</a></li> Drop explicit cargo protocol setting</a></li> Decouple recording monitor from DiagramModel</a></li> Implement system and address monitoring and recording</a></li> Load DiagramModel from file asynchronously</a></li> Stick at the bottom when an item is added to the diagram</a></li> Bump gtk4-rs version</a></li> Improve timestamp accuracy</a></li> Focus on the entry row when dialog presents</a></li> Save DiagramModel to file asynchronously</a></li> Further improve timestamp accuracy</a></li> Handle undefined behavior</a></li> Enable link-time optimization and various cleanups</a></li> Add loading and waiting pages on the window</a></li> Show a toast when clicking copy and other fixes</a></li> Implement diagram columns, arrows, and arcs</a></li> Improve loading performance and code organization</a></li> Implement API to get well-known names from bus names</a></li> Refactor name owner changed signal handling</a></li> Organize diagram files</a></li> Improve file naming</a></li> Monitor code cleanups</a></li> Add support for targeted signals</a></li> Port from libpcap to pcap-file</a></li> Use a more proper column width</a></li> Improving diagram tag styling</a></li> Properly update the color and label of RowTag</a></li> Improving diagram styling</a></li> Propagate errors to the user</a></li> Only show errors when necessary</a></li> Prevent copy when packet data is owned</a></li> Fix DiagramHeader labels UI glitch</a></li> ColorWidget and DiagramView cleanups</a></li> </ul> </span></a> zbus and gtk4-rs</h3> While the project is focused on Bustle, some changes are necessary to be upstreamed to other projects. This includes changes to zbus and gtk4-rs, where the following pull requests have been merged:</p> </span></a> zbus</h4> zb: Add a from_bytes constructor for Message</a></li> zv: Implement Display for Value, Array, Structure, Dict & Maybe</a></li> zv, zn: Improve Str, OwnedName, BusName Debug implementations</a></li> </ul> </span></a> gtk4-rs</h4> gdk: Make RGBA::new const and add with_ constructors</a></li> </ul> </span></a> Code to be Merged</h2> Due to time constraints and unexpected issues, some of the pull requests are still pending review:</p> Implement services filter</a></li> Port to GskPath APIs</a></li> Make use of GtkMapListModel for layouts</a></li> Implement BusNameList and FilteredBusNameModel</a></li> Fix header expanded height computation</a></li> </ul> </span></a> Future Plans</h2> While most of the tasks in the proposal have been completed, there are still a few things that need to be done, including the following:</p> Optimizing performance</li> Hunting and squashing bugs: Improving name owner changed signal handling</li> Drawing method call arc regardless if the row is not drawable</li> Properly killing the dbus-monitor</code> process</li> </ul> </li> Adding more features: Adding a button that scrolls to the method call message of a method return message or vice-versa</li> Adding a way to open multiple diagrams at once via tabs and multiple windows</li> </ul> </li> Fixing regressions and releasing the application on Flathub</li> Continuous involvement and contribution to open-source</li> </ol> </span></a> Final Words</h2> I have to say this is, so far, the most challenging part of my software development journey. It felt like a hackathon since I had to understand things and create something that works quickly. While it was challenging, it was also rewarding as I was able to learn a lot of things and create something that I am proud of. There were moments of time pressure and frustration, but with experimentation, collaboration, and a lot of reading, I was able to overcome these challenges and make meaningful progress. The complexity of the project pushed me out of my comfort zone, forcing me to delve into unfamiliar areas of programming and technology.</p> Lastly, I would like to express my gratitude to my mentors, Bilal Elmoussaoui</strong> and Maximiliano Sandoval</strong>, for tirelessly reviewing my pull requests and guiding me. I would also like to thank the GNOME Foundation and the community, especially the GNOME GSoC admin, Felipe Borges</strong>, for giving me the opportunity to work on this project. I would also like to extend my appreciation to zbus maintainer, Zeeshan Ali Khan</strong>, for their help in getting my pull requests merged against zbus and to the original Bustle developer, Will Thompson</strong>, for their guidance. Finally, I would like to thank my family and friends for their support and encouragement.</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 9 & 10) 2023-08-19T20:29:00.001+08:00 </span></a> Progress Made</h2> I am thrilled to announce that a lot of progress happened once again over the past few weeks! Starting with the most important thing, the diagram, a lot of bugs has been squashed and the rendering performance is now improved to a usable and merge-able state</a>.</p> </span> </p> Aside from that, it now has a header that doesn't overlay on the diagram, the drawings now properly adjust to text scale factor changes, the signal arrows are now drawn, and the rows are no longer clipped into the row titles.</p> My mentor, Bilal, also worked on adding tags</a>, the colored circles in the diagram, so it is easier to determine the category of a message.</p> On the general UI side, there is now a proper loading page</a> that is shown while waiting for the PCAP files to show.</p> </p> However, that may not be as useful as we also landed a patch</a> that speeds up loading by up to 32 times; that's from 16 seconds on average to 500 milliseconds, when loading a 2.2 MB file.</p> There is also now a waiting page that shows before the first message arrives while recording.</p> </p> We also landed statistics window</a> which shows frequencies of messages, durations of method calls, and sizes information of each message.</p> </p> </p> </p> My mentor, Bilal, also worked on adding information on the details view including the body size and signature, and the response time from method return to its call.</p> </p> There is also now a way to save the PCAP file as a DOT graph file</a>, which can be used to generate a graph using Graphviz to visualize interactions between bus names like the following:</p> </p> On the plumbing side, saving to PCAP file is now asynchronous</a>, avoiding blocking the UI. We also ported from using libpcap</code> to a pure Rust library, removing unsafe code and simplifying the codebase</a>. Furthermore, the timestamp computation is now more accurate</a>.</p> As part of making debugging in Bustle easier, I have also submitted a patch</a> to zbus</code> to simplify the printing of bus names.</p> Finally, I started prototyping services filtering. It is still a proof of concept and does not look great, but it already functions and is a good starting point for next week.</p> </p> </span></a> Plans for the Following Weeks</h2> The following weeks will be the last days of GSoC and I will be focusing on finishing up the remaining tasks. With the most difficult part of this GSoC project done, most of the tasks left, aside from services filtering, are optimizing performance and cleaning up the codebase.</p> There are also a few more things to fix such as a proper name owner changed signal handling, drawing method call arc regardless if the row is not drawable, properly killing the dbus-monitor</code> process, and propagating user-facing errors.</p> I would also like to add features such as adding a button that scroll to the method call message of a method return message or vice-versa, porting to use the new GskPath</code> APIs</a>, and adding a way to open multiple diagrams at once via tabs and multiple windows.</p> That's all for this week. Thanks for reading!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 7 & 8) 2023-08-02T18:29:00.001+08:00 </span></a> Progress Made</h2> A lot of things happened these past few weeks. First, the MR to add address and system DBus recording</a> has already been merged. Though, before that was merged, a few revisions have been made: it now parses from messages bytes directly, instead of a PCAP stream, to prevent overhead. Additionally, it now properly propagates errors, such as when the dbus-monitor</code> binary is not found.</p> </span> Second, when recording, the sequence diagram now sticks at the bottom</a> because, in common use cases, it is mostly wanted to observe the new messages as they come.</p> </p> Moreover, on the smaller changes, PCAP file loading is now synchronous</a>, the gtk4-rs dependency has now been updated to the recently released 0.17 version</a>, the accuracy of timestamp calculations has been improved</a>, and the focus issue on the address dialog has been fixed</a>.</p> Lastly, the signals and method call arrows and arcs are now (finally!) drawn in the diagram. While it looks simple, it took me days to get it right. However, there is no merge request yet since it requires more bug fixing and code cleanup.</p> </p> </span></a> GUADEC</h2> Aside from working on the code, I also attended GUADEC remotely. I had a lightning talk about a bit about myself and an overview of this project.</p> </span></a> Plans for the Following Weeks</h2> For the next weeks, the diagram still needs bug fixing and polishing, as mentioned. For instance, it currently does not draw arcs on method calls when either the call or return row is not visible. The header is also only visible when scrolled all the way to the top, and it only shows the unique name instead of the well-known name.</p> After the diagram is completed, we will go on with the implementation of service filtering and adding a more convenient way to have multiple instances of recording or opened files via tabs.</p> That's all for this week. Thanks for reading!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 5 & 6) 2023-07-19T11:51:00.002+08:00 </span></a> Progress Made</h2> This week, the PR to implement Display for Value, Array, Structure, Dict, and Maybe</a> has been merged. Thus, there is a much nicer way now upstream to display zbus::Value</code>, similar to GVariant</code>. With this blocker cleared out, the zbus port MR</a> has also been merged, fully porting the Bustle rewrite to zbus.</p> </span> Furthermore, my mentor, Bilal, started implementing session monitoring and saving to a PCAP file while I continued their work and implemented system and address recording</a>. However, it is not yet merged as there are some things to be figured out and more work to do. Specifically, it currently requires a dbus-monitor</code> binary installed on the host, which is not great for distributions that do not package it.</p> </p> Aside from those mentioned above, I have also been working on drawing the diagram. I am still studying the older Haskell codebase to prevent reinventing the wheel on some implementations. Unfortunately, the current implementation is still not ready enough for a screenshot.</p> To easily track the missing features, we also set up an issue board</a>.</p> </span></a> Plans for the Following Weeks</h2> In the following weeks, I will get the PR to implement and address recording merged and work on more parts of the diagram drawing.</p> That's all for this week. Thanks for reading!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 3 & 4) 2023-07-05T09:30:00.002+08:00 </span></a> Progress Made</h2> There's unfortunately not a lot to talk about for the past two weeks as I have been really absorbed with finals at my university. However, while preparing for the finals, we got the PR to add from_bytes</code> constructor for zbus::Message</code></a> merged. This means that we can now construct zbus::Message</code> from raw GDBusMessage</code> bytes and vice versa, which is critical for porting Bustle from GDBus to zbus.</p> </span> On the other hand, the PR to implement Display for Value, Array, Structure, Dict & Maybe</a> is, while the implementation for zbus::Value::Str</code> and zbus::Value::Array</code> is already fixed, still in the review stage as there are still things to polish, such as figuring out a way to simplify the implementation.</p> Meanwhile, I have also been experimenting with drawing on the diagram using GTK transform functions such as translate_coordinates</code> and compute_point</code>, but nothing is ready enough yet for a screenshot.</p> </span></a> Plans for the Following Weeks</h2> With my finals out of the equation, I could focus more on finishing up drawing the signals and methods arrow on the diagram during the last days of the GSoC midterm period.</p> I will also push PR to implement Display for Value, Array, Structure, Dict & Maybe</a> to be merged so that the zbus port MR</a> can also be merged.</p> That's all for this week. I'm looking forward to writing more in the next weeks. Thanks for reading!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 1 & 2) 2023-06-11T19:09:00.005+08:00 </span></a> Progress Made</h2> Before the GSoC coding period started, I started implementing the diagram used to display DBus activity with the help of the template repository made by my mentor, Maximiliano. One of the first challenges is figuring out how to load the PCAP files, which is the format Bustle uses to store the DBus messages. Without implementing that first, it would be difficult to test how the diagram will look like.</p> </span> The Rust PCAP library was used to load the packets from the PCAP file, which contains the bytes of a DBus Message. It is nice to use, though it is missing an async API for loading files. That could be fixed in the future, but this week mainly focused on a basic diagram implementation. The bytes can then be parsed through GDBus into a GDBusMessage</code>, which contains the information to implement the diagram.</p> Through the parsed message, the diagram can be implemented. It uses GtkListView</code> to display the rows as, aside from having a nice separation of view and model, it is more efficient because it recycles widgets, especially since PCAP files could possibly contain thousands of messages. Each row contains the elapsed time, path, destination, interface, and member of the message.</p> </p> Aside from the diagram, a DetailsView</code> was also implemented. It shows the sender and the body, and also the destination, path, and member of the message. For more information about it, you can check out the merge request</a>.</p> </p> GDBus was used initially as zbus is missing the necessary APIs for parsing messages from bytes. However, the merge requests are already on the way to implement those upstream, including a nicer way to print zbus::Value</code> that would match how GVariant</code>s are printed.</p> zv: impl Display for Value, Array, Structure, Dict & Maybe</a></li> zb: Add a from_bytes constructor for Message</a></li> </ul> </span></a> Plans for the Following Weeks</h2> While the merge requests are in place, there is still some work to do, such as fixing up the Display implementation for zbus::Value::Str</code> and zbus::Value::Array</code>. Once the mentioned merge requests are merged, we could finish up the zbus port</a>.</p> After the application is fully ported to zbus, we could start working on the more complicated part of the Diagram implementation, like showing signals and the method call and return arrows.</p> That's all for this week. See you again in the next weeks. Thanks for reading!</p> GSoC 2023: Rust and GTK 4 Bustle Rewrite (Introduction) 2023-05-11T23:17:00.003+08:00 Hello there!</p> I am Dave Patrick Caberto, a first-year Electronics Engineering student from Bataan Peninsula State University, Philippines. This summer, I will be working on the Rust and GTK 4 rewrite of Bustle, a D-Bus activity visualizer, with the guidance of my mentors, Bilal Elmoussaoui and Maximiliano Sandoval.</p> </span></span></a> Me and my bizarre open-source journey</h2> Weirdly enough, I first discovered Linux five years ago on a failed attempt to do Hackintosh. I got bored with Windows that I decided to try something new and different, and that's when I eventually stumbled upon Linux, specifically Elementary OS. It did not last for me since I still depend a lot on applications that are only available with Windows.</p> Fast-forward two years later, I decided to give Linux another try with KDE Neon and migrate my workflows to open-source applications such as LibreOffice, Inkscape, and Kdenlive. I remember feeling adventurous and breaking my system numerous times, though I considered it as part of the learning process. I was intrigued by the idea of being a part of a community of passionate developers and enthusiastic users. I also liked the customization it had. However, as I grew with it, I started to realize that I had spent way too much time configuring things and forgetting to focus on what was really important, and that is when I discovered GNOME.</p> When I first used GNOME, it was a totally different workflow, and I liked it. It was simple; the UI made sense. At that time, there was some software I was missing, particularly a screen recording application that works nicely on Wayland. That was the time I discovered RecApp. It worked well; however, it looked not at home, even for a GTK application. One of my first contributions was creating a mockup for the redesign, and I also took that opportunity to learn Python and GTK and implement my mockup. I was not necessarily proud of my code, but I was proud and happy about having the chance to contribute to the software I use and the community.</p> A few months later, as I learned more about programming and the GNOME developer ecosystem, there were many more things I'd like to improve and change in RecApp, some of which other contributors did not agree with. That's when Kooha was born, with a total in-and-out redesign of RecApp and a different focus and ideology. Almost a month later was also the birth of Mousai, a song recognizer application. Since then, I have been maintaining these two applications.</p> There are definitely a lot of things I missed, but that was a quick summary of my journey with open-source.</p> </span></a> More about Bustle and the project</h2> For those who have not heard of Bustle, it is an application used to visualize D-Bus activities. It shows signal emissions, method calls, method returns, and errors, which are useful in observing traffic, debugging, and optimizing performance in D-Bus applications.</p> </p> Although the current implementation of Bustle in Haskell and GTK 3 is functional, there are noteworthy reasons to consider a rewrite in Rust. Some of these advantages include having access to a range of libraries, such as zbus, gtk4-rs, and LibPCAP bindings. Aside from this, the growing Rust community and the availability of the Rust SDK in Flathub would make the tool more accessible to contributors and simpler to distribute to the users. On the other hand, porting Bustle to GTK 4 would over benefits such as the newer and more modern LibAdwaita widgets and ListView API, which would make it easier for the tool to comply with the HIG and benefit from the latest developments in the platform.</p> Altogether, this rewrite and port will contribute to the maintainability, accessibility, and future-proofing of Bustle through the use of newer technologies and arguably more ergonomic technologies.</p> I will be posting updates about the project every few weeks for the next few months, including more details about the plans for this GSoC project. If you'd like to talk about something, feel free to contact me at Matrix @sedve:matrix.org</code>.</p> Thanks for reading!</p> Browser Benchmark Comparison 2021: Chrome vs. Edge vs. Firefox vs. Brave vs. Chromium vs. Epiphany 2021-01-16T15:46:00.004+08:00 We all know that Google is already dominating the search engine share. Meanwhile, in terms of the browser market share, it is no different. Many browsers nowadays such as Brave and even Microsoft Edge are based on Google's open-source project, Chromium.</p> </span> In this article, I will compare various popular web browsers. Four of them use Blink/V8 as their engine while Firefox and GNOME Web (Epiphany) use Gecko and WebKitGTK respectively.</p> I ran eight benchmarks to test the performance of these browsers. I also measured the RAM usage of each browser manually using GNOME System Monitor. Note that if you replicate this test, your results may differ because you are probably using a different computer.</p> Spoiler alert... Chrome wins!</strong></p> </span></a> Setup</h2> I used a Laptop that is connected to a wall socket to do this comparison.</p> Intel i3-2310M</li> 3 GB DDR3</li> Fedora 33 Workstation Edition</li> Linux 5.10.6</li> GNOME Shell 40.0 on Wayland</li> </ul> </span></a> Browser used</h3> All are set in their default configurations. No additional extensions are installed. I tested two variants of Firefox, one with WebRender enabled.</p> Firefox 84.0.2</li> Firefox 84.0.2 (gfx.webrender.all set to true)</li> Chrome 87.0.4280.141</li> GNOME Web 3.38.2</li> Chromium 87.0.4280.88</li> Brave 1.18.78</li> Edge Dev 89.0.760.0</li> </ul> </span></a> Results</h2> </span></a> MotionMark 1.0</h3> MotionMark</a> is used to measure a browser's capability to animate complex scenes at a target frame rate.</p> </span></a> Brave wins!</h4> </p> </span></a> Kraken 1.1</h3> Kraken</a> is a JavaScript performance benchmark that measures the speed of browsers through different tests extracted from real-world applications and libraries.</p> </span></a> Chrome wins!</h4> </p> </span></a> Octane 2.0</h3> Octane</a> is a benchmark that measures a JavaScript engine's performance through a suite of tests representing certain use cases in JavaScript applications.</p> </span></a> Epiphany wins!</h4> </p> </span></a> WebXPRT 3</h3> WebXPRT</a> measures the performance of a browser through six HTML5 and JavaScript scenarios that mirror real-life tasks.</p> </span></a> Epiphany wins!</h4> </p> </span></a> Maze Solver (30x30)</h3> Maze Solver</a> exercises the browser's handling of CSS 2.1 and CSS 3 layer constructs which are important components of overall web browser performance.</p> </span></a> Epiphany wins!</h4> </p> </span></a> Speedometer 2.0</h3> Speedometer</a> is a browser benchmark that measures the responsiveness of web applications.</p> </span></a> Chrome wins!</h4> </p> </span></a> RAM Usage with 5 tabs open</h3> I opened a total of five tabs: YouTube, Reddit, DuckDuckGo, GitHub and New York Times.</p> </span></a> Firefox wins!</h4> </p> </span></a> Overall Results</h3> </span></a> Chrome wins!</h4> </p> Take note that I didn't include Basemark and JetStream results on the overall average as Firefox and Epiphany were not able to run these benchmarks without crashing, at least on my hardware.</p> </span></a> Basemark Web 3.0</h3> Basemark Web</a> tests how well a browser performs on web-based applications.</p> </span></a> Epiphany wins!</h4> </p> </span></a> JetStream 2</h3> Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p> </span></a> Chrome wins!</h4> </p> </span></a> Conclusion</h2> In the end, all browsers are capable of handling daily tasks. As long as it provides you with regular security updates and also privacy, you do not need to switch to another web browser for a minuscule performance difference. And remember, performance should not be your only consideration on choosing a web browser. Have a nice day!</p> </span></a> Appendix</h2> These are the raw benchmark results:</p> </p> Best Linux Distros for Beginners in 2021 2021-01-14T17:29:00.004+08:00 Choosing a Linux distro is not an easy task. New users might be overwhelmed with the hundreds of distros to choose from compared to Windows with just a few versions to choose from. I cannot really tell you which is the best for you as we come with different needs and motives, but here is a list of Linux distros that will help you determine what could be the best for you.</p> </span> Note that this list may vary from user to user. The main criteria I use are ease of use, user experience, and software and hardware support.</p> </span></a> 5. Linux Mint</h2> </p> Pros</em></p> Very lightweight and snappy</li> Great experience for former Windows users</li> Great for older laptops</li> </ul> Cons</em></p> The desktop looks dated</li> </ul> Linux Mint</a> is an Ubuntu-based distro. It comes with the Cinnamon DE environment by default which is noticeably lighter compared to GNOME. But if you do not like Cinnamon, you can choose between XFCE and MATE which are both similarly fast and light desktop environments.</p> It comes with the traditional desktop experience, so it would work great for users who came from Windows. It is very customizable and there are a lot of themes to choose from.</p> </span></a> 4. Elementary OS</h2> </p> Pros</em></p> Very simple to use</li> It looks beautiful and minimal</li> Supportive app store to indie developers</li> </ul> Cons</em></p> You cannot choose other DE besides Pantheon</li> </ul> Elementary OS</a> is yet another Ubuntu-based distro, but the difference is that it comes with its own desktop environment, Pantheon, and a minimal set of applications. It is arguably macOS-inspired due to its design language, dock, and the system panel on the top.</p> To be honest, it is one of the most beautiful Linux distros and its minimalistic look adds to the beauty. The thing I like the most about Elementary OS is its app store which makes it seamless to help hard-working developers.</p> </span></a> 3. Pop!_OS</h2> </p> Pros</em></p> Great Nvidia support</li> Backed by a hardware-selling company</li> Disk encryption on by default</li> </ul> Cons</em></p> Desktop environment choice is limited to GNOME</li> Not very good with older hardware with less than 1 GB of RAM</li> </ul> Pop!_OS</a> is an Ubuntu-based Linux distro backed by System76. No wonder why they have better Nvidia driver support as the company backing them sells laptops powered by Nvidia.</p> It provides a snappy and polished experience with the help of a slightly-modified GNOME desktop environment. It also comes with an auto-tiling extension which could be handy for power users.</p> </span></a> 2. Ubuntu</h2> </p> Pros</em></p> Great out-of-the-box experience</li> Backed by a company</li> Many desktop environments to choose from</li> Great community support</li> </ul> Cons</em></p> GNOME DE could be heavy with older hardware</li> </ul> Ubuntu</a> is a Debian-based Linux distro that is backed by Canonical. It comes with GNOME as the default desktop environment, but it comes with others to choose from like Kubuntu (KDE), Lubuntu (LXQt), Ubuntu Mate, UbuntuDDE (Deepin), and many more.</p> It is simple and easy to operate once you get used to it. Community support is also one of its selling points due to its popularity. It also offers many useful preinstalled applications that could give you a head start.</p> </span></a> Honorable Mentions</h2> </span></a> OpenSUSE</h3> It is a distro that is sponsored by a German company, SUSE. You can choose a rolling or stable release. It might not focus on simplicity, but it offers the user great flexibility.</p> </span></a> Deepin</h3> It is a Debian-based distro that comes with its own desktop environment and set of applications. Not only that, but it is subjectively one of the best-looking distros aside from Elementary.</p> </span></a> Manjaro</h3> This is an Arch-based distro. It is like Arch, but it is already configured out-of-the-box without having to manually install the operating system.</p> </span></a> KDE Neon</h3> This is a Linux distro based on Ubuntu LTS versions. It comes with the latest and greatest KDE packages. KDE Plasma, I would say, is the most customizable desktop environment. It has great support with theme engines like Kvantum.</p> </span></a> Debian</h3> It is one of the oldest and most stable Linux distros out there. However, for developers, the packages in the repository may be out-of-date.</p> </span></a> 1. Fedora</h2> </p> Pros</em></p> Great open-source approach</li> Vanilla GNOME experience</li> Backed by Red Hat</li> Very polished experience</li> </ul> Cons</em></p> Software options might be limited</li> </ul> Fedora</a> is subjectively the best Linux distro of all time. Like Ubuntu, you are not limited to the GNOME desktop environment due to the variety of officially supported spins. It also comes with strictly FOSS-only preinstalled apps, which might limit your software choice if you do not add additional repositories.</p> It is great for laptops because they are packed with additional optimizations for better battery life. Furthermore, it is also easier to update the system as its application and system updates are handled within the same application, unlike Ubuntu.</p> </span></a> Conclusion</h2> There is really no best Linux distro. All distros have their purposes that will serve a specific person. No one can tell you what is the best Linux distro. This is just a guide to help you consider a distro that will work best for you. Why not fire up that VM and you can decide for yourself?</p> If you have opinions on the list, feel free to comment below. Have a good day!</p>

I hope you find Delineate as useful as I do. If you have any feedback or suggestions, feel free to open a discussion or issue on the GitHub repository</a>. Enjoy the release!</p>

Kooha is available on Flathub</a>. You can install it from there, and since all of our code is open-source and can be freely modified and distributed according to the license, you can also download</a> and build it from source.</p>

`</span></a> Plans for the Following Weeks</h2> In the following weeks, I will get the PR to implement and address recording merged and work on more parts of the diagram drawing.</p> That's all for this week. Thanks for reading!</p>`

MotionMark</a> is used to measure a browser's capability to animate complex scenes at a target frame rate.</p>

Kraken</a> is a JavaScript performance benchmark that measures the speed of browsers through different tests extracted from real-world applications and libraries.</p>

Octane</a> is a benchmark that measures a JavaScript engine's performance through a suite of tests representing certain use cases in JavaScript applications.</p>

WebXPRT</a> measures the performance of a browser through six HTML5 and JavaScript scenarios that mirror real-life tasks.</p>

Maze Solver</a> exercises the browser's handling of CSS 2.1 and CSS 3 layer constructs which are important components of overall web browser performance.</p>

Speedometer</a> is a browser benchmark that measures the responsiveness of web applications.</p>
Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Speedometer</a> is a browser benchmark that measures the responsiveness of web applications.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>
Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Basemark Web</a> tests how well a browser performs on web-based applications.</p>

Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

Jetstream</a> rewards browsers that start up quickly, execute code quickly and run smoothly.</p>

SeaDve

DIY 12V DC Power Supply

Introducing Delineate!

Kooha 2.3 Released!

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Final Overview)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 9 & 10)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 7 & 8)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 5 & 6)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 3 & 4)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Week 1 & 2)

GSoC 2023: Rust and GTK 4 Bustle Rewrite (Introduction)

Browser Benchmark Comparison 2021: Chrome vs. Edge vs. Firefox vs. Brave vs. Chromium vs. Epiphany

Best Linux Distros for Beginners in 2021