From fa6aded86998639a53aecfa7b76e0ecd800fd9f0 Mon Sep 17 00:00:00 2001 From: Bradley Taunt Date: Sun, 26 May 2024 12:35:41 -0400 Subject: More post cleanup, mobile styling fixes --- ...024-04-11-OpenBSD_is_a_Cozy_Operating_System.md | 34 ------------ .../2023-12-17-Switching_Things_Over_to_ikiwiki.md | 30 +++++++++++ ...2024-01-02-My_Text_Editor_Is_Not_Open_Source.md | 60 +++++++++++++++++++++ _posts/2024-01-29-New_Domain_and_Code_Forge.md | 63 ++++++++++++++++++++++ ...2024-02-16-Website_Backups_with_Apple_iCloud.md | 25 +++++++++ ...02-23-Please_Make_Your_Table_Headings_Sticky.md | 33 ++++++++++++ ...024-04-11-OpenBSD_is_a_Cozy_Operating_System.md | 34 ++++++++++++ _posts/My_Text_Editor_Is_Not_Open_Source.mdwn | 55 ------------------- _posts/New_Domain_and_Code_Forge.mdwn | 58 -------------------- _posts/OpenBSD_is_a_Cozy_Operating_System.mdwn | 28 ---------- _posts/Please_Make_Your_Table_Headings_Sticky.mdwn | 28 ---------- _posts/Switching_Things_Over_to_ikiwiki.mdwn | 25 --------- _posts/Website_Backups_with_Apple_iCloud.mdwn | 20 ------- 13 files changed, 245 insertions(+), 248 deletions(-) delete mode 100644 _posts/024-04-11-OpenBSD_is_a_Cozy_Operating_System.md create mode 100644 _posts/2023-12-17-Switching_Things_Over_to_ikiwiki.md create mode 100644 _posts/2024-01-02-My_Text_Editor_Is_Not_Open_Source.md create mode 100644 _posts/2024-01-29-New_Domain_and_Code_Forge.md create mode 100644 _posts/2024-02-16-Website_Backups_with_Apple_iCloud.md create mode 100644 _posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md create mode 100644 _posts/2024-04-11-OpenBSD_is_a_Cozy_Operating_System.md delete mode 100644 _posts/My_Text_Editor_Is_Not_Open_Source.mdwn delete mode 100644 _posts/New_Domain_and_Code_Forge.mdwn delete mode 100644 _posts/OpenBSD_is_a_Cozy_Operating_System.mdwn delete mode 100644 _posts/Please_Make_Your_Table_Headings_Sticky.mdwn delete mode 100644 _posts/Switching_Things_Over_to_ikiwiki.mdwn delete mode 100644 _posts/Website_Backups_with_Apple_iCloud.mdwn (limited to '_posts') diff --git a/_posts/024-04-11-OpenBSD_is_a_Cozy_Operating_System.md b/_posts/024-04-11-OpenBSD_is_a_Cozy_Operating_System.md deleted file mode 100644 index b2b4a84..0000000 --- a/_posts/024-04-11-OpenBSD_is_a_Cozy_Operating_System.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: "OpenBSD is a Cozy Operating System" -date: 2024-04-11 ---- - -
-Screenshot of OpenBSD 7.5 running dwm -
OpenBSD 7.5 running dwm on my X220
-
- -With the recent release of OpenBSD 7.5, I decided to run through my [personal OpenBSD "installer"](https://git.btxx.org/open-suck/about/) for laptop/desktop devices. The project is built off of the `dwm` tiling window manager and only installs a few basic packages. The last time I updated it was with the release of 7.3, so it's been due for an minor rework. - -While making these minor changes, I remembered how incredibly easy the entire install process for OpenBSD is and how *cozy* the entire operating system feels. All the core systems just work out the box. Yes, you need to "patch" in WiFi with a firmware update, so you'll need an Ethernet connection during the initial setup. Yes, the default desktop environment is not intuitive or ideal for newcomers. - -But the positives heavily outweigh the negatives (in my opinion): - -- Incredibly secure operating system (No `xz` drama here...) -- Detailed documentation. Probably one of the best of any OS -- Much smaller codebase and small core team -- *Complete* operating system (kernel, userland utilities, libraries, applications combined) - -These points might not seem important to others, but they are to me. Maybe you're possibly interested in checking it out yourself? If you are, then read on... - -## Try it Yourself! - -I've tried my best to write up a simplified, noob-friendly guide on both setting up the core OpenBSD system, along with installing a simple `dwm` based desktop environment. These are both focused on personal devices (laptops/computers), so if you're looking for server-specific setups you won't find that here! - -You can find both of those wiki-pages below: - -- [Installing OpenBSD](https://btxx.org/wiki/openbsd/installation/) -- [Setting up a Desktop Environment for OpenBSD](https://btxx.org/wiki/openbsd/desktop_environment/) - -Some additional reading I highly recommend is: [c0ffee.net/blog/openbsd-on-a-laptop](https://www.c0ffee.net/blog/openbsd-on-a-laptop) \ No newline at end of file diff --git a/_posts/2023-12-17-Switching_Things_Over_to_ikiwiki.md b/_posts/2023-12-17-Switching_Things_Over_to_ikiwiki.md new file mode 100644 index 0000000..393919a --- /dev/null +++ b/_posts/2023-12-17-Switching_Things_Over_to_ikiwiki.md @@ -0,0 +1,30 @@ +--- +layout: post +title: Switching Things Over to ikiwiki +--- + +I've done it again. My personal website is no longer generated with [barf](https://barf.bt.ht) but is instead built on top of [[ikiwiki]]. The old RSS feed ([bt.ht/atom.xml](https://bt.ht/atom.xml)) still exists but will no longer receive updates. The new feed can be found on the bottom of the homepage ([index.rss](/index.rss)) + +## Why a Wiki? + +I love the simplicity of a minimal blog, which is why I always gravitated towards purely "static" site builders. Over time though, I found two minor issues that slowly chipped away at me: ease-of-use and flexibility. + +I had a vision, back when I began tinkering with my own place on the web, of building out my own personal "resource center" or wiki. Often times through work or personal projects I stumble into little problems that I need to solve. Most times I find a solution and move on with my life. The problem with this approach is *lack of documentation*. + +What if I come across that issue at a later point in time? Will I even remember my old solution? Probably not. So, I've made the switch to a more flexible, personal wiki (which also happens to be a blog!) + +## Text Editors, Terminals, and Web UI - Oh My! + +[[ikiwiki]] comes packed with multiple ways to publish pages and posts. Since it is built with [[ikiwiki/git]] version control in mind, you have the ability to push out changes directly to your server similar to that of pre-existing static site generators. It also gives you the choice to `ssh` directly into your server and publish content from your terminal if you so desire. + +Best of all, [[ikiwiki]] offers a web UI interface. This is something I have long missed since leaving "dynamic" websites behind. + +## But Wait, There's More! + +Did I mention that this site now supports a built-in search form *and* a comment system? I've been wanting comments or discussions directly on my personal web space for the longest time and now I do! The search function is really an added bonus, mostly for my own personal use to find something I documented quickly. + +## Broken Links and Bugs + +I've done my best to properly forward all original posts and pages to their new URLs - but I'm sure some things will be overlooked. So please feel free to reach out and let me know if anything seems broken. + +I look forward to growing out this "platform" and seeing how it impacts my workflow writing documentation / blog posts. I hope you'll come along for the ride! diff --git a/_posts/2024-01-02-My_Text_Editor_Is_Not_Open_Source.md b/_posts/2024-01-02-My_Text_Editor_Is_Not_Open_Source.md new file mode 100644 index 0000000..d92c361 --- /dev/null +++ b/_posts/2024-01-02-My_Text_Editor_Is_Not_Open_Source.md @@ -0,0 +1,60 @@ +--- +layout: post +title: My Text Editor Is Not Open Source +--- + +I've been using Sublime Text on and off for longer than I can remember. I think Sublime has been around since the start of my "real" career over 10 years ago, but I could be mistaken[^1]. It certainly *feels* that long. And in that time I have never gotten upset with Sublime. I've never rage quit or ran into an issue of Sublime not being able to *do the thing I wanted it to do*. As much of a cliche it may sound: it just works. + +Even when I switch editors (VSCode, Geany, kitty+vim etc.) for a period of time, I find myself always coming back to Sublime. The only reason I try other editors is simply that: to try them. Maybe that's why these editors don't click with me. Maybe I'm giving Sublime an unfair advantage since I'm simply "testing" other editors, rather than looking for a solid alternative. + +And don't get me wrong, I understand *why* editors like VSCode are extremely popular. VSCode has a massive ecosystem and new plugins are generally developed for that editor before all others. Finding solutions to problems online is very easy, since it is so popular. But best of all - it's open source[^2]. + +So why am I using a *non*-open source editor? (Spoilers: because it's a great editor) + +## "A Proprietary Editor - How Could You?!" + +I know, I know. If you're familiar with me or the things I write about it must seem odd that I would willingly use proprietary software over open source. This is something I struggle with constantly day-to-day in the realm of "personal tech". I find with age I become more open-minded to having a diverse range of software and hardware choices. Open source is best in *concept* but not always best in practice. + +The problem is that Sublime is just such a *great* editor. I can't ignore quality and refuse to use good software solely based on it's licensing. A few personal things I love about Sublime: + +- Incredibly fast +- Handles massive files without breaking a sweat +- Minimal resource footprint (ex. uses <0.1% CPU working on huge projects) +- Large ecosystem of plugins/themes +- No Electron + +Other editors can certainly check off a few of those boxes as well, but you'd be hard-pressed to find one that checks off them all. + +## Being a Cheapskate + +I must confess something that I think most Sublime users are guilty of: I've never [bought a license](https://www.sublimehq.com/store/text). I've installed and used Sublime on countless machines, on multiple operating systems from Linux to Windows to MacOS. That `Unregistered` text in the top right application bar has been with me since the beginning. But that in no longer the case. + +**I finally purchased a license.** I bundled it with [Sublime Merge](https://www.sublimemerge.com/), so it ended up costing me $168 USD. When I initially looked at that price tag I must admit I was tempted to close the browser tab and forget the whole thing. But then I realized I have been using this editor *free of charge* for over 10 years. (Not to mention using Sublime Merge for quite some time as well!) + +So I did a little math: + + $168 / 10 years = $16.80 + +Looking at it in that perspective, it's actually a great deal. Not to mention they have very respectable terms for their licenses: + +> Personal licenses come with 3 years of updates. After 3 years, you'll be able to continue to use the last version released within 3 years of purchase (in other words, licenses do not expire). Any versions released 3 years or more after the purchase date will require a paid upgrade to use. + +> Individual licenses are valid for 3 years of updates, but do not expire after 3 years. Only if you wish to use newer versions will an upgrade fee be required. + +> Licenses are per-user, so you're welcome to use the one license on all computers and operating systems where you are the primary user. + +I won't copy everything from their main [FAQ page](https://www.sublimehq.com/sales_faq) but as you can see it is very reasonable. I also get to feel decent for supporting developers who make very good software. + +## Final Notes + +This post is not meant to convince you to switch or anything of that nature. Use what works for you! I just wanted to share my own personal preference when it came to my main text editor. Maybe this will also convince "hardcore" open source people (like me!) to realize it is *okay* to pay for software sometimes... + +--- + +I should be very clear about something: this post *is not an advertisement*. I have not received any money or "kick backs" to write about my happy times with Sublime. This is purely my own opinion that I wanted to share with the internet! + +BTW if anyone from SublimeHQ happens to come across this post: PLEASE look into building a "native" version of Sublime Text for FreeBSD/OpenBSD. I (and many others) would be forever grateful! + +[^1]: Sublime does mention copyright since 2006... + +[^2]: Not the pre-packaged Microsoft version diff --git a/_posts/2024-01-29-New_Domain_and_Code_Forge.md b/_posts/2024-01-29-New_Domain_and_Code_Forge.md new file mode 100644 index 0000000..e2f451b --- /dev/null +++ b/_posts/2024-01-29-New_Domain_and_Code_Forge.md @@ -0,0 +1,63 @@ +--- +layout: post +title: New Domain and Code Forge +--- + +As you can clearly see, my site's domain has switched over to **btxx.org**. This post will go into details about the reason for this URL swap (spoilers: I'm a cheapskate) - but that isn't all. I have moved my personal git repositories over to my own hosting. I will explain the reasoning for that switch as well. + +But enough introductions, let's get into it! + +## bt.ht is No More + +I've abandoned `bt.ht`. Well, kind of. That domain doesn't expire until 2025, which works out nicely since I can keep a complete web forward active for the entire year. This will avoid such a radical switch, similar to what I did years ago with my "uglyduck" domain[^1]. Hopefully anyone who follows my dumb ramblings will have more than enough time to become familiar with the new URL. + +For reference, those interested in updating their RSS will need to use the latest URLs: + +- [RSS](https://btxx.org/index.rss) +- [Atom](https://btxx.org/index.atom) + +You have roughly a year to do so, since new posts should still automatically appear even with defaulting to the older URL (hooray for 301 redirects!). + +There were two core reasons for switching domains. The first was based off a change in ownership with my previous domain registrar, Gandi. You can read more details [here](https://news.ycombinator.com/item?id=35080777), but they were essentially bought out, then decided to cancel their free email service and raised their prices. Not many registrars support the `.ht` TLD, so moving to another provider was already proving to be difficult. Once my mind was made up that I didn't want to support such shady actions from a company, I thought even more about the concept of spending *so much* on a domain name in the first place. It was a novelty to have such a "short" domain, but that seems silly in hindsight. + +Just take a look at the differences in domain costs and email services below: + +|URL|Domain/year|Email/year|Total| +|---|-----------|----------|-----| +|bt.ht|$172|$60|$232| +|btxx.org|$17|$19|$36| + +By making this switch (for both my domain and email service) I would save a yearly total of **$196 USD**. This was a no-brainer. The minute I did the math I thought, "Hell, I'm already moving everything to a different registrar *and* I need to look for a separate email provider...why not just start fresh with a new, *cheaper* domain?" + +So that's what I've done. + +## My Own Code Forge + +As some people in the open source community might already be aware, [sourcehut](https://sourcehut.org) had a major outage a couple weeks back. It lasted a few days and all services were impacted. This meant that all publicly hosted websites, build processes and `git` repositories were unavailable. It was no fault of sourcehut of course, they were viciously attacked for no *real* reason. + +But this outage did get me thinking about what it means to "control" my own code. I always liked the idea of hosting my own git projects but relied on third-party services since they were more convenient. The problem with entrusting anything, not just code storage, to third-party services is lack of oversight. You really have no idea what is happening behind the scenes. You don't control your own backups. You don't have the freedom to tweak UI or user flow of your project views (which I understand is certainly an edge-case). + +These thoughts lead me to research some "self-hosted" code forge options. My main contenders were: + +- GitWeb +- cgit +- Gitea + +I'll save you the suspense: I went with cgit. Getting GitWeb configured properly was giving me a lot of issues and Gitea seemed overkill for my person needs. I host through NearlyFreeSpeech (running FreeBSD) and they had a decent tutorial for setting cgit up on their servers. I've updated my own wiki for those interested in doing something similar: [read the full step-by-step instructions for setting up cgit](/wiki/cgit). + +I still need to go through most of the existing projects on sourcehut and update their READMEs and purge the contents. The last thing I want to do is have users confused about which repo is the "real" one. + +Fore reference the my repos are now located here: [git.btxx.org](https://git.btxx.org) + +(I plan to place this in the main navigation soon...) + +## Mirror, Mirror on the Wall... + +I'm aware that to have extra protection from "downtime" that I should also mirror my code on separate forges. I plan to do this sometime in the future, but this isn't a major priority for me currently. When the time comes I'll be sure to update my repos referring to the mirrors (whatever platform that is I choose). + +## Room for Improvement + +My code forge is far from perfect. Mobile view is lacking, there is no dark mode support and things could be slightly more intuitive. But I love it. The beauty of hosting everything on my own is that I can improve these things myself. For now, I'm happy with the outcome! + + +[^1]: Someone oddly picked up that domain and piggybacked off the back-links. They happen to also be a designer...Guess the naming was that cool? 🤷‍♂️ diff --git a/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md b/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md new file mode 100644 index 0000000..e8836e6 --- /dev/null +++ b/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md @@ -0,0 +1,25 @@ +--- +layout: post +title: Website Backups with Apple iCloud +--- + +My main work machine, an M2 MacBook Air, meshes really well with my iPhone SE (they are in the same ecosystem after all - duh!). Since both of these devices are Apple products, it makes sense that I pay for the optional iCloud service for extra storage. 50GB to be exact. I only need to bare minimum which costs just $1.68 a month, making this storage option cheaper than most cups of coffee these days. + +Recently I've been using iCloud as my "middle-man" backup system. I still have local, offline storage for most personal data but having additional off-site backups is never a bad thing. I make things easier for myself by taking advantage of `rsync`. You'll need to make sure you have that program installed before trying this yourself: + + # This assumes you have homebrew installed first + brew install rsync + +Then, whenever I feel like backing up an existing project or website I simply run: + + rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup + +> Note: The `-a` option tells `rsync` to sync directories recursively, transfer special and block devices, preserve symbolic links, modification times, groups, ownership, and permissions. + +The beautiful magic of `rsync`! Obviously, you'd want to properly name your directories (ie. `/Backups/site-backup`) for a cleaner structure and ensure that your iCloud directory is set correctly. (remember to read code before just copy-pasting!). With this approach you can backup entire server directories or be specific with each individual project folder. I would also recommend setting up some alias in your `.bashrc` or `.zshrc` etc. to make things more streamlined when running backups manually: + + alias site-backup="rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup" + # Then you simply run the following for a manual backup: + site-backup + +You can take this further by automating things via cron jobs, but for my use case that is a little overkill. Hopefully this helps anyone looking for a quick and dirty backup system, especially one that can piggyback of your existing iCloud that you might be paying for already. diff --git a/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md b/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md new file mode 100644 index 0000000..c9005e4 --- /dev/null +++ b/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md @@ -0,0 +1,33 @@ +--- +layout: post +title: Please Make Your Table Headings Sticky +--- + +I often stumble upon large data sets or table layouts across the web. When these tables contain hundreds of rows of content, things become problematic once you start to scroll... + + + +Look at that table header disappear! Now, if I scroll all the way down to item #300 (for example) will I remember what each column's data is associated with? If this is my first time looking at this table - probably not. Luckily we can fix this (no pun intended!) with a tiny amount of CSS. + +## Sticky Header + +Check it out: + + + +Pretty awesome, right? It might look like magic but it's actually very easy to implement. You only need to add 2 CSS properties on your `thead`: + + position: sticky; + top: 0; + +That's it! Best of all, `sticky` has [~96% global support](https://caniuse.com/?search=sticky) which means this isn't some "bleeding-edge" property and can safely support a ton of browsers. Not to mention the improved experience for your end-users! + +You can view a live demo of this table on the [CodePen example pen](https://codepen.io/bradleytaunt/pen/bGZyJBj). + +If you found this interesting, feel free to check out my other table-focused post: [Making Tables Responsive With Minimal CSS](https://btxx.org/posts/tables/) diff --git a/_posts/2024-04-11-OpenBSD_is_a_Cozy_Operating_System.md b/_posts/2024-04-11-OpenBSD_is_a_Cozy_Operating_System.md new file mode 100644 index 0000000..b2b4a84 --- /dev/null +++ b/_posts/2024-04-11-OpenBSD_is_a_Cozy_Operating_System.md @@ -0,0 +1,34 @@ +--- +layout: post +title: "OpenBSD is a Cozy Operating System" +date: 2024-04-11 +--- + +
+Screenshot of OpenBSD 7.5 running dwm +
OpenBSD 7.5 running dwm on my X220
+
+ +With the recent release of OpenBSD 7.5, I decided to run through my [personal OpenBSD "installer"](https://git.btxx.org/open-suck/about/) for laptop/desktop devices. The project is built off of the `dwm` tiling window manager and only installs a few basic packages. The last time I updated it was with the release of 7.3, so it's been due for an minor rework. + +While making these minor changes, I remembered how incredibly easy the entire install process for OpenBSD is and how *cozy* the entire operating system feels. All the core systems just work out the box. Yes, you need to "patch" in WiFi with a firmware update, so you'll need an Ethernet connection during the initial setup. Yes, the default desktop environment is not intuitive or ideal for newcomers. + +But the positives heavily outweigh the negatives (in my opinion): + +- Incredibly secure operating system (No `xz` drama here...) +- Detailed documentation. Probably one of the best of any OS +- Much smaller codebase and small core team +- *Complete* operating system (kernel, userland utilities, libraries, applications combined) + +These points might not seem important to others, but they are to me. Maybe you're possibly interested in checking it out yourself? If you are, then read on... + +## Try it Yourself! + +I've tried my best to write up a simplified, noob-friendly guide on both setting up the core OpenBSD system, along with installing a simple `dwm` based desktop environment. These are both focused on personal devices (laptops/computers), so if you're looking for server-specific setups you won't find that here! + +You can find both of those wiki-pages below: + +- [Installing OpenBSD](https://btxx.org/wiki/openbsd/installation/) +- [Setting up a Desktop Environment for OpenBSD](https://btxx.org/wiki/openbsd/desktop_environment/) + +Some additional reading I highly recommend is: [c0ffee.net/blog/openbsd-on-a-laptop](https://www.c0ffee.net/blog/openbsd-on-a-laptop) \ No newline at end of file diff --git a/_posts/My_Text_Editor_Is_Not_Open_Source.mdwn b/_posts/My_Text_Editor_Is_Not_Open_Source.mdwn deleted file mode 100644 index 31ae7db..0000000 --- a/_posts/My_Text_Editor_Is_Not_Open_Source.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -I've been using Sublime Text on and off for longer than I can remember. I think Sublime has been around since the start of my "real" career over 10 years ago, but I could be mistaken[^1]. It certainly *feels* that long. And in that time I have never gotten upset with Sublime. I've never rage quit or ran into an issue of Sublime not being able to *do the thing I wanted it to do*. As much of a cliche it may sound: it just works. - -Even when I switch editors (VSCode, Geany, kitty+vim etc.) for a period of time, I find myself always coming back to Sublime. The only reason I try other editors is simply that: to try them. Maybe that's why these editors don't click with me. Maybe I'm giving Sublime an unfair advantage since I'm simply "testing" other editors, rather than looking for a solid alternative. - -And don't get me wrong, I understand *why* editors like VSCode are extremely popular. VSCode has a massive ecosystem and new plugins are generally developed for that editor before all others. Finding solutions to problems online is very easy, since it is so popular. But best of all - it's open source[^2]. - -So why am I using a *non*-open source editor? (Spoilers: because it's a great editor) - -## "A Proprietary Editor - How Could You?!" - -I know, I know. If you're familiar with me or the things I write about it must seem odd that I would willingly use proprietary software over open source. This is something I struggle with constantly day-to-day in the realm of "personal tech". I find with age I become more open-minded to having a diverse range of software and hardware choices. Open source is best in *concept* but not always best in practice. - -The problem is that Sublime is just such a *great* editor. I can't ignore quality and refuse to use good software solely based on it's licensing. A few personal things I love about Sublime: - -- Incredibly fast -- Handles massive files without breaking a sweat -- Minimal resource footprint (ex. uses <0.1% CPU working on huge projects) -- Large ecosystem of plugins/themes -- No Electron - -Other editors can certainly check off a few of those boxes as well, but you'd be hard-pressed to find one that checks off them all. - -## Being a Cheapskate - -I must confess something that I think most Sublime users are guilty of: I've never [bought a license](https://www.sublimehq.com/store/text). I've installed and used Sublime on countless machines, on multiple operating systems from Linux to Windows to MacOS. That `Unregistered` text in the top right application bar has been with me since the beginning. But that in no longer the case. - -**I finally purchased a license.** I bundled it with [Sublime Merge](https://www.sublimemerge.com/), so it ended up costing me $168 USD. When I initially looked at that price tag I must admit I was tempted to close the browser tab and forget the whole thing. But then I realized I have been using this editor *free of charge* for over 10 years. (Not to mention using Sublime Merge for quite some time as well!) - -So I did a little math: - - $168 / 10 years = $16.80 - -Looking at it in that perspective, it's actually a great deal. Not to mention they have very respectable terms for their licenses: - -> Personal licenses come with 3 years of updates. After 3 years, you'll be able to continue to use the last version released within 3 years of purchase (in other words, licenses do not expire). Any versions released 3 years or more after the purchase date will require a paid upgrade to use. - -> Individual licenses are valid for 3 years of updates, but do not expire after 3 years. Only if you wish to use newer versions will an upgrade fee be required. - -> Licenses are per-user, so you're welcome to use the one license on all computers and operating systems where you are the primary user. - -I won't copy everything from their main [FAQ page](https://www.sublimehq.com/sales_faq) but as you can see it is very reasonable. I also get to feel decent for supporting developers who make very good software. - -## Final Notes - -This post is not meant to convince you to switch or anything of that nature. Use what works for you! I just wanted to share my own personal preference when it came to my main text editor. Maybe this will also convince "hardcore" open source people (like me!) to realize it is *okay* to pay for software sometimes... - ---- - -I should be very clear about something: this post *is not an advertisement*. I have not received any money or "kick backs" to write about my happy times with Sublime. This is purely my own opinion that I wanted to share with the internet! - -BTW if anyone from SublimeHQ happens to come across this post: PLEASE look into building a "native" version of Sublime Text for FreeBSD/OpenBSD. I (and many others) would be forever grateful! - -[^1]: Sublime does mention copyright since 2006... - -[^2]: Not the pre-packaged Microsoft version diff --git a/_posts/New_Domain_and_Code_Forge.mdwn b/_posts/New_Domain_and_Code_Forge.mdwn deleted file mode 100644 index 8039d8d..0000000 --- a/_posts/New_Domain_and_Code_Forge.mdwn +++ /dev/null @@ -1,58 +0,0 @@ -As you can clearly see, my site's domain has switched over to **btxx.org**. This post will go into details about the reason for this URL swap (spoilers: I'm a cheapskate) - but that isn't all. I have moved my personal git repositories over to my own hosting. I will explain the reasoning for that switch as well. - -But enough introductions, let's get into it! - -## bt.ht is No More - -I've abandoned `bt.ht`. Well, kind of. That domain doesn't expire until 2025, which works out nicely since I can keep a complete web forward active for the entire year. This will avoid such a radical switch, similar to what I did years ago with my "uglyduck" domain[^1]. Hopefully anyone who follows my dumb ramblings will have more than enough time to become familiar with the new URL. - -For reference, those interested in updating their RSS will need to use the latest URLs: - -- [RSS](https://btxx.org/index.rss) -- [Atom](https://btxx.org/index.atom) - -You have roughly a year to do so, since new posts should still automatically appear even with defaulting to the older URL (hooray for 301 redirects!). - -There were two core reasons for switching domains. The first was based off a change in ownership with my previous domain registrar, Gandi. You can read more details [here](https://news.ycombinator.com/item?id=35080777), but they were essentially bought out, then decided to cancel their free email service and raised their prices. Not many registrars support the `.ht` TLD, so moving to another provider was already proving to be difficult. Once my mind was made up that I didn't want to support such shady actions from a company, I thought even more about the concept of spending *so much* on a domain name in the first place. It was a novelty to have such a "short" domain, but that seems silly in hindsight. - -Just take a look at the differences in domain costs and email services below: - -|URL|Domain/year|Email/year|Total| -|---|-----------|----------|-----| -|bt.ht|$172|$60|$232| -|btxx.org|$17|$19|$36| - -By making this switch (for both my domain and email service) I would save a yearly total of **$196 USD**. This was a no-brainer. The minute I did the math I thought, "Hell, I'm already moving everything to a different registrar *and* I need to look for a separate email provider...why not just start fresh with a new, *cheaper* domain?" - -So that's what I've done. - -## My Own Code Forge - -As some people in the open source community might already be aware, [sourcehut](https://sourcehut.org) had a major outage a couple weeks back. It lasted a few days and all services were impacted. This meant that all publicly hosted websites, build processes and `git` repositories were unavailable. It was no fault of sourcehut of course, they were viciously attacked for no *real* reason. - -But this outage did get me thinking about what it means to "control" my own code. I always liked the idea of hosting my own git projects but relied on third-party services since they were more convenient. The problem with entrusting anything, not just code storage, to third-party services is lack of oversight. You really have no idea what is happening behind the scenes. You don't control your own backups. You don't have the freedom to tweak UI or user flow of your project views (which I understand is certainly an edge-case). - -These thoughts lead me to research some "self-hosted" code forge options. My main contenders were: - -- GitWeb -- cgit -- Gitea - -I'll save you the suspense: I went with cgit. Getting GitWeb configured properly was giving me a lot of issues and Gitea seemed overkill for my person needs. I host through NearlyFreeSpeech (running FreeBSD) and they had a decent tutorial for setting cgit up on their servers. I've updated my own wiki for those interested in doing something similar: [read the full step-by-step instructions for setting up cgit](/wiki/cgit). - -I still need to go through most of the existing projects on sourcehut and update their READMEs and purge the contents. The last thing I want to do is have users confused about which repo is the "real" one. - -Fore reference the my repos are now located here: [git.btxx.org](https://git.btxx.org) - -(I plan to place this in the main navigation soon...) - -## Mirror, Mirror on the Wall... - -I'm aware that to have extra protection from "downtime" that I should also mirror my code on separate forges. I plan to do this sometime in the future, but this isn't a major priority for me currently. When the time comes I'll be sure to update my repos referring to the mirrors (whatever platform that is I choose). - -## Room for Improvement - -My code forge is far from perfect. Mobile view is lacking, there is no dark mode support and things could be slightly more intuitive. But I love it. The beauty of hosting everything on my own is that I can improve these things myself. For now, I'm happy with the outcome! - - -[^1]: Someone oddly picked up that domain and piggybacked off the back-links. They happen to also be a designer...Guess the naming was that cool? 🤷‍♂️ diff --git a/_posts/OpenBSD_is_a_Cozy_Operating_System.mdwn b/_posts/OpenBSD_is_a_Cozy_Operating_System.mdwn deleted file mode 100644 index 6c4dd5a..0000000 --- a/_posts/OpenBSD_is_a_Cozy_Operating_System.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -
-Screenshot of OpenBSD 7.5 running dwm -
OpenBSD 7.5 running dwm on my X220
-
- -With the recent release of OpenBSD 7.5, I decided to run through my [personal OpenBSD "installer"](https://git.btxx.org/open-suck/about/) for laptop/desktop devices. The project is built off of the `dwm` tiling window manager and only installs a few basic packages. The last time I updated it was with the release of 7.3, so it's been due for an minor rework. - -While making these minor changes, I remembered how incredibly easy the entire install process for OpenBSD is and how *cozy* the entire operating system feels. All the core systems just work out the box. Yes, you need to "patch" in WiFi with a firmware update, so you'll need an Ethernet connection during the initial setup. Yes, the default desktop environment is not intuitive or ideal for newcomers. - -But the positives heavily outweigh the negatives (in my opinion): - -- Incredibly secure operating system (No `xz` drama here...) -- Detailed documentation. Probably one of the best of any OS -- Much smaller codebase and small core team -- *Complete* operating system (kernel, userland utilities, libraries, applications combined) - -These points might not seem important to others, but they are to me. Maybe you're possibly interested in checking it out yourself? If you are, then read on... - -## Try it Yourself! - -I've tried my best to write up a simplified, noob-friendly guide on both setting up the core OpenBSD system, along with installing a simple `dwm` based desktop environment. These are both focused on personal devices (laptops/computers), so if you're looking for server-specific setups you won't find that here! - -You can find both of those wiki-pages below: - -- [Installing OpenBSD](https://btxx.org/wiki/openbsd/installation/) -- [Setting up a Desktop Environment for OpenBSD](https://btxx.org/wiki/openbsd/desktop_environment/) - -Some additional reading I highly recommend is: [c0ffee.net/blog/openbsd-on-a-laptop](https://www.c0ffee.net/blog/openbsd-on-a-laptop) diff --git a/_posts/Please_Make_Your_Table_Headings_Sticky.mdwn b/_posts/Please_Make_Your_Table_Headings_Sticky.mdwn deleted file mode 100644 index 7ecda82..0000000 --- a/_posts/Please_Make_Your_Table_Headings_Sticky.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -I often stumble upon large data sets or table layouts across the web. When these tables contain hundreds of rows of content, things become problematic once you start to scroll... - - - -Look at that table header disappear! Now, if I scroll all the way down to item #300 (for example) will I remember what each column's data is associated with? If this is my first time looking at this table - probably not. Luckily we can fix this (no pun intended!) with a tiny amount of CSS. - -## Sticky Header - -Check it out: - - - -Pretty awesome, right? It might look like magic but it's actually very easy to implement. You only need to add 2 CSS properties on your `thead`: - - position: sticky; - top: 0; - -That's it! Best of all, `sticky` has [~96% global support](https://caniuse.com/?search=sticky) which means this isn't some "bleeding-edge" property and can safely support a ton of browsers. Not to mention the improved experience for your end-users! - -You can view a live demo of this table on the [CodePen example pen](https://codepen.io/bradleytaunt/pen/bGZyJBj). - -If you found this interesting, feel free to check out my other table-focused post: [Making Tables Responsive With Minimal CSS](https://btxx.org/posts/tables/) diff --git a/_posts/Switching_Things_Over_to_ikiwiki.mdwn b/_posts/Switching_Things_Over_to_ikiwiki.mdwn deleted file mode 100644 index 0d016d1..0000000 --- a/_posts/Switching_Things_Over_to_ikiwiki.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -I've done it again. My personal website is no longer generated with [barf](https://barf.bt.ht) but is instead built on top of [[ikiwiki]]. The old RSS feed ([bt.ht/atom.xml](https://bt.ht/atom.xml)) still exists but will no longer receive updates. The new feed can be found on the bottom of the homepage ([index.rss](/index.rss)) - -## Why a Wiki? - -I love the simplicity of a minimal blog, which is why I always gravitated towards purely "static" site builders. Over time though, I found two minor issues that slowly chipped away at me: ease-of-use and flexibility. - -I had a vision, back when I began tinkering with my own place on the web, of building out my own personal "resource center" or wiki. Often times through work or personal projects I stumble into little problems that I need to solve. Most times I find a solution and move on with my life. The problem with this approach is *lack of documentation*. - -What if I come across that issue at a later point in time? Will I even remember my old solution? Probably not. So, I've made the switch to a more flexible, personal wiki (which also happens to be a blog!) - -## Text Editors, Terminals, and Web UI - Oh My! - -[[ikiwiki]] comes packed with multiple ways to publish pages and posts. Since it is built with [[ikiwiki/git]] version control in mind, you have the ability to push out changes directly to your server similar to that of pre-existing static site generators. It also gives you the choice to `ssh` directly into your server and publish content from your terminal if you so desire. - -Best of all, [[ikiwiki]] offers a web UI interface. This is something I have long missed since leaving "dynamic" websites behind. - -## But Wait, There's More! - -Did I mention that this site now supports a built-in search form *and* a comment system? I've been wanting comments or discussions directly on my personal web space for the longest time and now I do! The search function is really an added bonus, mostly for my own personal use to find something I documented quickly. - -## Broken Links and Bugs - -I've done my best to properly forward all original posts and pages to their new URLs - but I'm sure some things will be overlooked. So please feel free to reach out and let me know if anything seems broken. - -I look forward to growing out this "platform" and seeing how it impacts my workflow writing documentation / blog posts. I hope you'll come along for the ride! diff --git a/_posts/Website_Backups_with_Apple_iCloud.mdwn b/_posts/Website_Backups_with_Apple_iCloud.mdwn deleted file mode 100644 index cd1aa98..0000000 --- a/_posts/Website_Backups_with_Apple_iCloud.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -My main work machine, an M2 MacBook Air, meshes really well with my iPhone SE (they are in the same ecosystem after all - duh!). Since both of these devices are Apple products, it makes sense that I pay for the optional iCloud service for extra storage. 50GB to be exact. I only need to bare minimum which costs just $1.68 a month, making this storage option cheaper than most cups of coffee these days. - -Recently I've been using iCloud as my "middle-man" backup system. I still have local, offline storage for most personal data but having additional off-site backups is never a bad thing. I make things easier for myself by taking advantage of `rsync`. You'll need to make sure you have that program installed before trying this yourself: - - # This assumes you have homebrew installed first - brew install rsync - -Then, whenever I feel like backing up an existing project or website I simply run: - - rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup - -> Note: The `-a` option tells `rsync` to sync directories recursively, transfer special and block devices, preserve symbolic links, modification times, groups, ownership, and permissions. - -The beautiful magic of `rsync`! Obviously, you'd want to properly name your directories (ie. `/Backups/site-backup`) for a cleaner structure and ensure that your iCloud directory is set correctly. (remember to read code before just copy-pasting!). With this approach you can backup entire server directories or be specific with each individual project folder. I would also recommend setting up some alias in your `.bashrc` or `.zshrc` etc. to make things more streamlined when running backups manually: - - alias site-backup="rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup" - # Then you simply run the following for a manual backup: - site-backup - -You can take this further by automating things via cron jobs, but for my use case that is a little overkill. Hopefully this helps anyone looking for a quick and dirty backup system, especially one that can piggyback of your existing iCloud that you might be paying for already. -- cgit v1.2.3-54-g00ecf