June 06 2020
About a month back on my personal Twitter, I made a post about getting my own dial-up system going. I wanted to explain what it took to get everything working as there were quite a few people interested in this project.
My setup consisted of a 1993 Apple PowerBook 160 running System 7.1 (and later a 1998 PowerBook G3 "Wallstreet"), one Raspberry Pi to act as the dial-up server, one virtual machine running Issabel PBX (a CentOS-based Linux distribution intended as an easy-to-use PBX solution), two Grandstream HT701 ATAs, and a US Robotics Sportster 56k modem. And, of course, some phone cable.
The setup was pretty simple, starting out with Issabel PBX running on my desktop computer in VMware Workstation. Once installed, I logged into the web interface, set up two extensions for the two Grandstream HT701s, manually configured both the HT701s via their web interfaces, set up the Raspberry Pi with the US Robotics modem plugged into one HT701, and my PowerBook 160 plugged into the other. On the Raspberry Pi end, I set up minicom on /dev/ttyUSB0 where the modem was active on. On the PowerBook 160, I dialed the Raspberry Pi, and was met with some moderate success. Both devices were able to communicate, but something was very wrong as the handshake almost always failed, or if it did succeed, the connection would almost immediately disconnect. With the basic setup out of the way, it was time to delve a bit deeper and start the troubleshooting process.
The first thing that I thought could be an issue was jitter, or dropped packets. Although everything was running through my LAN, it could still theoretically be an issue. So, I spent several hours adjusting the jitter on Issabel with mixed results. Sometimes it seems like it'd work longer, sometimes it'd seem like it got worse. No matter what, it seemed like regardless of what I tried, jitter didn't appear to be an issue. However, to rule out the possibility of this being an issue down the road, I set up a very small jitter buffer. You want to keep your jitter buffer very small here as the bigger it is, the more latency you'll have.
The next thing I looked into is the codec being used. As we're using our VoIP system to send data through, we want to ensure that we're using something uncompressed and high-quality. However, after having a look at both Issabel and the Grandstream ATAs, both were set to use G.711 U-LAW which is the best codec to use in a situation like this. Again, I didn't see this as the problem and left it alone.
The next thing I decided to try was seeing if I could get any connection going at all by adjusting the link speed manually on the US Robotics modem connected to the Pi instead of letting it determine the speed on its own. At first I tried the absolute lowest it could go, 300 baud, and it still didn't work for some reason. However, upon trying 1200 baud, I finally got a stable connection going.
But still, that was only 1200 baud. I tried 2400 baud and was able to get it connected as well, but it was a lot less stable. The modems would have to retrain almost every few seconds, and the connection would often drop. I refused to believe that 1200 baud was the fastest that this setup could pull a connection at, but it was very late and I was tired, so I stopped working on it for the night.
I slept on it a bit and when I woke up, I thought about something and some friends on Twitter also pointed out exactly what I was thinking: echo cancellation. Most ATAs have some form of it enabled by default, and that could be what's wreaking havoc on the data connection. I got everything set back up, checked the Grandstream ATAs, and sure enough, echo cancellation was enabled on both. Disabled it, tried dialing again without manually specifying a speed, and... success. I brought out the PowerBook G3 which had a much faster modem than the 160 to really test out speeds. Everything was perfect now.
The last step I wanted to do now that all the pieces were together was making the Raspberry Pi automatically answer the calls and provide a terminal over this data connection. This was as simple as installing mgetty and configuring it to listen automatically on /dev/ttyUSB0. With that set, I tried it out one more time and... bingo, we had a real dial-up server.
There is more that can be done with this, such as setting up PPP to allow for direct Internet access through dial-up, but I haven't done this as of yet. If you are interested in getting to that point, there's a great write-up on Doge Microsystems that explains how to go about doing this.
There is also the possibility of doing something even crazier, such as connecting an ATA wirelessly, connecting it using a VPN tunnel at a different location... or both. Essentially, you could have your own dial-up system anywhere if you wanted to get to that point... and that may be a post for a later time.
February 13 2020
The Deneb Kaitos main website has had a pretty significant theme refresh for 2020. As you can tell, there's a lot of dark colors and a very lovely shade of pink. This is known as the Sakura theme.
Originally I was thinking about what to do regarding introducing a dark mode theme to the Deneb Kaitos website, and for a while I really just wanted to keep the previous purple theme and make it work with dark mode. Ultimately though, the light pink on dark pink/gray is a color combination that works really well together. I've used a theme like this before with my previous Ultra desktop and I've always been fond of the way that it looked.
Some other design changes have been made, including condensing everything down a bit and straightening some things out that were overlooked back when the website was first brought online in 2017. You may also notice that the post titles are now ALL UPPERCASE. It just fits the overall theme of the website better.
On top of the theme refresh, I'm happy to announce that the Deneb Kaitos main website is now running on the new server and everything is (mostly) working as expected. The only issue is that the Downloads page isn't pretty looking due to an issue that's still being worked out and should hopefully be resolved soon. This server, like Satellaview, is spec'd better so things should generally run smoothly (though smoothness was never an issue with the old web server).
That's all for now. Enjoy the refresh and new servers! As a reminder, if you're a user of Performa, please make sure to migrate over to Satellaview as soon as possible to prevent any data loss.
Also please note that things may continue being a bit rocky over today and tomorrow as I finish up some tasks on this new server. Should any issues occur, it's likely I had to take the website back offline for an issue but it should come back up shortly.
February 03 2020
The Deneb Kaitos website will be going down for maintenance & a design refresh starting on 2/13 and ending on 2/14. Satellaview and Performa will be available for use during this downtime and will not be affected by the maintenance.
January 30 2020
The Deneb Kaitos server "Performa" will be replaced at the end of February by "Satellaview". This server is already active, and any users of Performa should be able to access it using their login credentials as normal. This is being done as Performa is running an old version of Debian, with LTS support ending later this year. The new server also bumps up the specifications a fair amount, so it should be faster to use.
If you have any important files on Performa, you will be responsible for transferring them over to Satellaview before it is shut down.
The server that runs the Deneb Kaitos website will be updated soon as well; stay tuned. A post will be made after the maintenance is scheduled.
September 24 2019
Back in 2011, after having used GNOME 2 for such a long time prior, I one day ran an update on my Arch-based system... and was thrown into GNOME version 3.0. It was bad. Like, really bad. It felt as if the developers had forgotten that devices without touchscreens existed and didn't care about customizability or usability any longer. I was so disappointed -- along with so many others on the internet, even Linus Torvalds himself. I tried very hard to like GNOME 3, but ultimately I couldn't stand it.
After I got sick of GNOME 3, I tried out many other desktop enviroments. KDE, XFCE, LXDE... Each one had their own set of things that I didn't like about it. However, there were things about each that I did like. KDE looked wonderful. XFCE was very customizable. LXDE was very modular. I wanted to be able to pick and choose the features of each that I liked. So, late into the night on a late-Spring day, I got to work on piecing together a desktop that would suit my needs well. This would be the ultimate desktop -- or, as I would call it, the Ultra desktop.
The Ultra Desktop consisted of multiple bash scripts that would manage launching individual components of the desktop environment. One for the panel (which was XFCE4's panel), one for the dock (which was Docky), and one for Compiz, which was chosen to allow for some nice compositioning effects. There were other functions that handled other tasks that would normally be done automatically in a desktop enviroment such as GNOME, like enabling ConsoleKit, PolicyKit, etc. Shutting down, logging off, restarting were all done using a modified version of qtLogout, accessible through the menu. Logging on was done through an old version of GDM, with a custom theme to accompany it.
I worked on and used Ultra a lot from 2011 up to the Summer of 2014. When I purchased my new (at the time) laptop, it came with a touchscreen, which I knew that Ultra was never designed for. I decided to try out GNOME 3 again, which was at version 3.12 at the time. I ended up really liking it after doing some customizations and using some extensions. I decided to keep it on my new laptop.
Within a couple of months, I had stopped working on Ultra entirely. Once it stopped working properly after system updates, I switched over to GNOME 3 on my desktop as well. The Ultra Desktop was now defunct, collecting dust in a folder on my desktop computer, along with all of my other old projects. Early in 2015, I started to consider releasing everything that made up Ultra, but decided to hold back on it and see if I could clean it up and make it functional once more before doing so, along with writing some documentation on how to set it up and get it working.
That never ended up happening, and unfortunately, at the beginning of Summer of 2015, my desktop computer, the only thing having a backup of all of the old Ultra files and programs/scripts on it, along with almost everything of mine from before that point, was forcefully stolen from me, never to be seen again. Those events are a subject for a different time, and likely not on here.
After building a new desktop PC a couple of months after, I had a near-100% clean slate, whether I liked it or not. Everything was gone, but the idea behind Ultra stuck with me. I still liked GNOME, but there were things I felt could be improved, such as the look and functionality. I also wanted stability and an easier way to bring up a GNOME desktop with the customizations already done to it. For the distribution, I had chosen Debian, which had just released version Jessie (8.0) a few months prior, and had GNOME 3.14. I was familiar with it and knew exactly what I liked by default, and what I wanted to change.
I started work on a new project which I called "EDC". This project, when run on a clean Debian install, allowed for bringing up a system just the way that I wanted it: clean-looking, lightweight and rock-solid stable. I have been using this project on all of my computers since 2015, updating it to work on Stretch in 2017 and Buster this year, 2019. For the version that works on Buster, I decided to rename it Eridanus.
I do plan to release Eridanus one day, but not right now. I had mentioned previously wanting to do so as well, but I feel that I need to iron out a lot of issues to actually make it a usable project for others.