But the best laid plans often go awry…
It’s been a long semester for me. Despite not having a numerically harder schedule in raw credits, I’ve been buried under a continual avalanche of things needing to get done. My sleep app informs me that I’ve only gone to bed before 3AM once this week, a trend that’s not going to be broken tonight as I write this due to what I have due tommor-… er, well… today.
However, I’ve broken a lot of software this semester, so I have plenty of blog posts that I need to write… some day… In the mean time, the first of the blog posts for the independent study I’m doing this semester have had someone proofread them, so they have been scheduled to go live over the next week. My main site has fallen fairly out of date, but that’s ok because I’m rebuilding it from the ground-up and the content is also going to get some much-needed love.
In addition to the usual business of making sure that things don’t burn down, here’s some of what I’ve been up to:
- Crazy Jekyll templating on the RITlug website (repo here)
- Adapting to apartment & commuter life
- Doing server work
- Bit of club work to try to keep things moving
- Mostly breaking almost all of m personal infra setup
- Turns out that Ubuntu doesn’t do a good job of cleaning up old kernels, so I had the experience of using
rm with a wildcard in
- Trying to balance security with convenience in a low-scale environment that isn’t reliably secure
And here’s a list of blog posts I need to write someday:
- A few more blog posts about my independent study
- Problems of high-end computing at a low scale
- I broke almost my entire home lab, what I learned, & how I’m re-engineering it
- Why I don’t like Docker – the problems of qualitative scaling
- Moving my laptop to Linux not-to-plan & the experience. Also what I’m planning to do in the next iteration
- A visual walkthrough of Git and evaluating a GitHub profile, based on showing a non-computing professor how this works
- How to Jekyll – both the basics & some cool stuff
- Moved my website to a VPS & made it PaaS
- Rewriting my portfolio site (post will come after I finish)
Well, the posts are scheduled and I’m going back to being buried for a couple weeks, but hopefully I can get some more posts going soon.
An Arduino project to run simple Photoshop commands at the press of a button (and not the ones on your keyboard).
Continue reading “[PCOMP] Arduino Controller for Photoshop”
This post is as a result of multiple failures of the Matrix<->Freenode bridge recently, and what I’ve learned using Matrix daily for several months.
The first note on Matrix is that depending on how the server/internet feels, it can take 30 seconds for a message to send, sometimes even longer. This can make debugging a bit more difficult, but ~30 seconds is a good cut-off if you are waiting for a message to send.
The first part of identifying how broken the bridge is is to look at if messages are coming though. If neither side is getting the other’s messages, then the bridge is potentially down. Matrix often reports this sort of outage on their Twitter & Mastodon, but don’t rely on that alone. When debugging it’s helpful to have another connection to the other side, such as using Freenode’s web chat. In #rit-foss we also have a bot that will respond if you send the message “test”
The bridge isn’t as simple as a boolean up/down though. You might discover that messages are going one-way. I’ve seen it go one-way in both directions before. And it can get even weirder. If you’re really familiar with IRC you probably know how there are multiple servers and what a netsplit is. Well, it would appear that the bridge can sometimes fail to recognize certain servers. I’ve seen cases in which I can only see a couple people talking, and also where I can see everyone except a couple people.
The most frustrating part of this is that since Matrix controls the infrastructure, you can’t a lot about this. Thankfully, the server and bridge are both open source, so you could run your own infrastructure, but that doesn’t solve the larger issue and also begs the question of whether you want to have to maintain it.
Ultimately this article fails fixing the issue, but hopefully helps is figuring out where and how bad the issue is when it does occur
This post has come about from a couple really bad experiences with documentation this week, and what I found frustrating in those experiences.
Continue reading “The importance of good docs”
Project 3 was to do something interactive with audio. After some failures with audio input libraries, I managed to dig up a text-to-speech library for Arduino on GitHub. I then used a couple switches and a button to do binary-encoded input for selecting options in a menu. The project isn’t very expansive in its options right now, but it’s easily scalable. Due to the quality of the speaker output (I didn’t have time to build in the amp circuit that was provided for one), this also shows an interesting cognitive property of the brain in that if it knows what it’s hearing it can match the sound to the words (like with subtitles).
Some (not all) of the lines:
I am nothing but a simple Arduino, nothing to see here.
This article hopes to pass along personal experience I’ve had with asking to use non-“normal” software/formats.
Continue reading “Asking to use FOSS or an Open Standard”
Mail servers are handy, even if you’re just using them for internal logging like I am.
Continue reading “Server Setup pt. 5 – Mail”
What is FOSS?
FOSS (“Free and Open Source Software”) is the idea that software you use should be free (more on what free means later) and that the code should all be publically available to all.
Continue reading “FOSS in Design: What is FOSS and why does it matter?”
This project stems from an in-depth discussion (explained here) about the lack of FOSS being used within RIT’s design programs. More specifically, this project will be aimed at students, who have a very short time frame for work and already have some base knowledge of relevant concepts. I intend for this project to be applicable outside of students but when making priorities the student audience will be the most important consideration (when relevant). I feel that trying to bridge the gap is the most effective way to beget usage, as opposed to trying to completely retrain users or rewrite software.
What this project WILL (attempt to) do:
- Centralize/aggregate existing information about how to use FOSS software
- Create resources to bridge the gap in understanding between traditional/”industry standard” software/workflows with FOSS ones
- Focus on what’s available now rather than saying to come back in a year [or any other distant amount of time] (as a student, a couple months is most often a really long time (the scope of assignments is often a week and for many projects still less than a month); the luxury to wait is not something easily viable)
- Explanation of basic FOSS concepts, limited to what’s directly relevant for target audience (who is expected to have little/no familiarity with FOSS)
- Attempt to build a reasonable expectation for how the software will work compared to the nearest traditional/”industry standard” software
What this project will NOT be:
- A comprehensive training manual for the everything relating to a given field; some base knowledge of concepts is assumed
- A moral/ethical manifesto; I’ll explain why FOSS is good, but I’m not going to force you to use it, nor force you to accept other’s morals/ethics (although you’re welcome to choose to do so)
- An explanation for why you can’t do your homework; you might have a specific feature that isn’t supported, and you might need to revert to Photoshop (or another piece of software) to do that; it happens occasionally
What does success look like?
A successful outcome would be having a readily-available resource to allow users familiar with traditional/”industry standard” software to be able to be able to pick up and use FOSS software with minimal adjustments to their workflow beyond some initial setup. Over time, familiarity with the toolchain will create the ability to go outside what they’re familiar with, but this project will aim specifically for a “grab & go”-style approach on the part of the end users.
What is the desired outcome?
Greater access to FOSS and open standards as acceptable methods of making and submitting work, or where that is not possible that ability to use FOSS and open standards to the fullest extent within a preexisting ecosystem.
What would I like to see in 3-5 years?
I would like to see FOSS & open standards to be accepted as a valid method of doing student work. Additionally, I would like to see it accepted in “the industry” if development is capable of making it industry-ready. For this project it’ll just mean that my work is easier and this project gets cleaner instructions.