diff options
Diffstat (limited to 'org/blog/articles')
| -rw-r--r-- | org/blog/articles/network-diarrhea.xml | 58 | ||||
| -rw-r--r-- | org/blog/articles/the-command-line-reactionary.xml | 57 |
2 files changed, 115 insertions, 0 deletions
diff --git a/org/blog/articles/network-diarrhea.xml b/org/blog/articles/network-diarrhea.xml new file mode 100644 index 0000000..53fa308 --- /dev/null +++ b/org/blog/articles/network-diarrhea.xml @@ -0,0 +1,58 @@ +<article> + <h2>The thing that happened</h2> + <p> + I have noticed really bad inbound latency on the VPS I host this site + on. Way slower than what <a href="https://skhron.eu">skhron</a> says it + should be on their site so clearly something was up. I noticed when pinging + <a href="https://example.com">example.com</a> the first ping took a while + but after that it was fine compared to pinging its IP address which was + pretty much instant so clearly the DNS server was shit. While doing this I + had the VPS dashboard open and saw DNS server settings which I assumed + (assuming things often lead to bad outcomes) would change something on the + DHCP server. After that I noticed the network on the VPS go completely + down. Only way I could get in was with VNC and from the server I couldn't + ping anything not even IP addresses. After changing back to the default DNS + the issue continued. Turned out there is no DHCP the VPS server just + configures everything statically with some scripts and it messed up. I use + freebsd which wasn't well tested by whoever made that system so it nuked + itself. + <br /><br /> + Even after turning on manual mode and setting up the networking by + hand it was still fucked. The only thing I backed up was my git repos. All + the configs (some of them a pain in the ass to make) were stuck on there + without any way to get them off except painfully hand copy with the 80 + column VNC display. Linux live environments don't support zfs and the + drivers to make that happen require rebooting which live environments reset + on boot. Uploading freebsd live images to the VPS would be painful due to + the stuppa way it handles them. + <br /><br /> + Because I didn't want to go through any of those things I contacted tech + support (I hate contacting those types of places). Most places have an + under powered LLM running the show, people who have good writing/talking + skills but have computer skills limited to using word processors and web + browsers, over worked intern who has million other things on their + mind... Skhron turned out to be one of the rare gems that has tech support + that not only knows what they are doing but also has the time/will to do + so. The tech support person actually took the time to recreate the issue on + another freebsd instance while most tech support people by now would have + sent a copy pasted corporate answer that translates to "go fuck + yourself". After a few hours they sent a manual route config which fixed it + and they also said to configure DNS from <code>/etc/resolv.conf</code> + instead. + </p> + + <h2>What was learned</h2> + <p> + Less so when using more popular operating systems on a VPS but do be + careful with dashboard settings that might be changing things in the + operating system itself instead of on the network and VM. If you can + preform a task from a config file that is often the safer choice because + you don't know what the fuck the VPS dashboard is doing behind the + scenes. Also anything you don't want to loose make backups of because even + if you do everything right things will still fuck up! If this issue wasn't + fixed a fresh install would have been the only other option. If up time is + important for you then automatic backups and full backups are a must + have. Regardless keep an offline backup of important things on your own + hard drive. + </p> +</article> diff --git a/org/blog/articles/the-command-line-reactionary.xml b/org/blog/articles/the-command-line-reactionary.xml new file mode 100644 index 0000000..a8d64fd --- /dev/null +++ b/org/blog/articles/the-command-line-reactionary.xml @@ -0,0 +1,57 @@ +<article> + <p> + Modern GUI fucking suck. Very little customization, mobile first design, + <i>GNOMEism</i>, electron... A lot of things to dislike indeed which will + of course lead to people disliking. Some even lump all of this into one + thing and blame GUI in general. Those are people I call command line + reactionaries. + </p> + + <h2>Why command line is wonderful</h2> + <p> + When I write things people (often willingly) misunderstand what I + say. <b>No, I am not saying command line programs are bad.</b> In fact here + is a list of why they are wonderful: + </p> + <ul> + <li>Simple to write, test, and maintain.</li> + <li>Easily automated and used from other programs.</li> + <li>Doesn't have themeing and integration issues when used in some desktop + environments and window managers.</li> + <li>Screen reader friendly unless you really fuck it up.</li> + <li>Can be used over ssh or telnet.</li> + <li>Slightly more dummy prove from shitty developers.</li> + <li>Heavily keyboard focused.</li> + <li>Can be used in the tty.</li> + </ul> + + <h2><i>Why do I write this if command line good</i></h2> + <p> + There is this generally held belief with some unix users GUI programs can't + be good. They will make command line versions of programs purely as a + reaction to the GUI version sucking. Quickly this turns to just making a + command line version for everything once the black and white "GUI + inherently bad" mindset kicks in. File manager? Ranger (even though ls, + touch, rm... exist). Email? Mutt. These programs existence is a net + positive but did anyone ever stop to think "what if we made and use GUI + programs that don't suck?". Some tasks are just plain annoying to do from + the command line yet the command line versions get more development and the + GUI implementations are left up to beginner python programmers who can't + get the most out of python yet alone use a better language. Those kinds of + programmers I speak of also fall for bad software design philosophy the + most. TUI programs are also kind of stuppa. They cross out a few of the + things on the command line is wonderful list without getting that much + closer to the advantages of GUI programs. + </p> + + <h2>What to do about it</h2> + <p> + We need GUI programs that don't use libraries programmed with one desktop + environment in mind. Use pure gtk and qt instead. GUI programs should work + in both wayland and X11 not one or the other. No more annoying popups and + treating the user like they don't know what they are doing. We need config + files and customization even if its possible for the user to <i>break + it</i>. GUI programs shouldn't be the dummy option, they should be the + graphical option. + </p> +</article> |