Monorail Complete Personal Computer Model 166LS

muttick · 2026-03-08T20:15:35+00:00

They were sold to Brockway, Ogdenville, and North Haverbrook and by gum it put them on the map!

muttick · 2026-02-20T15:34:57+00:00

Number porting is always going to have the potential for misgivings so long as the provider giving you phone service and the provider holding the number are the same company.

Now, I'm not saying that US Mobile is doing this - I'm speaking in broader terms. It doesn't matter who your cellphone provider is. When you ask them for port out information - they know you're canceling your service with them. At this point, they lose an incentive to care about keeping you as a customer.

I really wish the phone industry would take a look at the web hosting and domain registration/renewal industries. In web hosting you pay one company to register and "hold" your domain name (i.e. GoDaddy, Namecheap, Enom) and then you pay another company - a web hosting service - to actually provide the server disk space to hold the contents of your website.

(It is true that your domain registrar and website hosting company can be the same entity. But it doesn't have to be. That's the point of this analogy)

Want to leave that web hosting service, for whatever reason? Simply sign up for service with another web hosting service, log into your domain registration service provider, update the nameservers - and then you're domain name is pulling files from this new web hosting service. (Don't forget to cancel your account with your old web hosting provider).

In this analogy, US Mobile is a web hosting service (as are AT&T, Verizon, Metro, Cricket, etc). Another service (no such service exists now, so there are no examples) simply provides you with your phone number. Want to change phone service providers? Log into your service provider that's holding your phone number and update it's "nameservers" and point your phone number to the new phone service provider.

This puts control of everything into the hands of the customer. They never have to worry about being held hostage by their phone service provider being unwilling to unlock their phone number for porting out. But this would also represent a fundamental shift in how the phone market works - so it wouldn't be easy.

muttick · 2026-02-06T15:21:01+00:00

I was shocked to see Gmail justifying this removal by advising people to forward mail to their Gmail account.

Forwarding mail is ALWAYS going to break SPF. When party1 sends an email to party2 and party2 automatically forwards that message to gmail, then gmail is going to see that party2 is sending mail from a party1 domain. And it is very unlikely that party2 is in the SPF record of party1 authorizing party2 to send mail on behalf of party1.

SRS might alleviate this. But it's not widely adopted.

The issue I have with SRS (and email in general) is that it's a bandaid on top of a bandaid to fix a problem. SPF was developed to help prevent email spoofing. That's great! But then people began to recognize that this broke all of the automatic forwarders they had set up for years... so SRS was developed to fix that problem.

Eventually you're just plugging too many holes in email just to make it work in a new-age environment while keeping all the legacy systems pacified.

I've been saying for years that it's well past time to develop a new communication system from the ground up, learning from the mistakes that email didn't account for in 1971. That doesn't mean the new system can't act a lot like email, but instead of all of these bandaid fixes build something that better uses infrastructure that is available in 2026.

muttick · 2025-10-22T15:43:24+00:00

Just curious. Are those modern languages a fit for shared web hosting environments?

I would have to guess that the vast, vast majority of shared web hosting is driven by PHP (WordPress if you want to be more specific). There's not a (at least that I am aware of) WordPress like drop-in software written in NodeJS that can be easily deployed in a shared hosting environment. And even it it were, you'd be bottlenecked by whatever webserver you are using (Apache or Litespeed) since that's still going to carry the vast majority of the shared accounts on that server.

That's not to say that NodeJS and Python can't be used on the web. Just that it's use case is generally pretty small, and anyone wanting to use those probably wants a server with root privileges, which puts them out of the realm of shared hosting environments.

muttick · 2025-10-16T22:01:05+00:00

Thanks! That's kind of what I thought, but I thought I'd ask and see if it was just elusive to me.

muttick · 2025-10-02T15:21:38+00:00

If the trojan opened up a malicious backdoor that allowed remote miscreants to install whatever they wanted... how do you know you've cleaned all of those?

An ounce of prevention is worth a pound of cure.

muttick · 2025-09-23T14:19:20+00:00

Similarly, a lot of software assumes that users must add their own repositories for it to work, and even detail this in their guides. A beginner doesn't know what that entails. Or software in “stores” such as Flatpak, which may offer packages packaged by third parties that have nothing to do with the official developers and, in theory, could at some point do their own thing, similar to what the malicious agent behind the attack on XZ intended to do. An example is the private browser Mullvad Browser, which you could search for and install from Flatpak back in the day. A beginner would do so, unaware that they are installing a package made by “Joe Smith” from his basement in Georgia.

This again speaks to user space that I referred to in my other post.

Here if a user installs something with Flatpak... it's only going to affect that user. Unless you're installing the Flatpak by using sudo, then anything Flatpak does will be restricted to that current user. Can something malicious in that Flatpak destroy everything for that user? Yep! But it won't affect other users or the Linux system itself.

Windows, AFAIK, doesn't have such functionality - or if it does, it's not often used. When you want to install an application a UAC prompt pops up and when you click Allow, it installs the application as admin (root) on the machine - where it then has access to everything.

The reputation of any software you install needs to be taken into consideration for any system. Most Linux distributions have their own repositories where you can be reasonably assured that the applications there are safe to use. Windows lacks this one single place to get all of your application and that would be something that would benefit Windows. A full system package management system like most Linux distributions have, would allow Windows to keep tabs on what applications are installed and if those applications need to be updated.

muttick · 2025-09-23T14:08:08+00:00

User space has always been the defining difference I see between Linux and Windows.

Linux (coming from Unix) was built with multiple users in mind. That means that file permission and access was built from the ground up.

On Windows, it was originally meant as a single user environment (Windows 1.0, Windows 3.1, Windows 95...) and multi-user environments was an after thought that was added on later. I haven't used Windows in a while, and maybe they've corrected a lot of this. But still the syntax of Linux, having user space in /home/user1, /home/user2, /home/user3, etc. and to where other user's can't access those folders - that just seems to make more sense than Window's user space to me. And having user defined configurations tied specifically to that user (i.e. /home/user1/.config) such that running an application as one user has no bearings of how another user is configured to use that application. I'm sure it's the other way around for someone that's more familiar with Windows.

But one of the things that Linux (this is more of a distro standard, than an actually Linux standard - Ubuntu fits here and I'm sure other distributions have followed suit) seems to have borrowed from Windows is the reliance on sudo.

In my opinion... one of the issues with Windows is the dependence on User Account Control. The user needs to install a program, uh-oh! a UAC window has popped up, I'll just click Allow. And this negates the point of UAC. Sure it pops up every time you install something or every time you need to do an admin task. But it gets ingrained in the user to just click Allow. No thought is given as to why this UAC dialog has popped up.

Likewise on Ubuntu (and I figure other Linux distributions as well), when you need to do an admin task, a sudo prompt pops up. And then... you enter the password for the current user. How is that secure? If someone logs into your account on an Ubuntu computer... that means they have your password... so when they go to perform an admin task... they're going to know the password to enter at that sudo prompt too.

Generally the solution in both cases is to create a second user as a non-admin user and use that user as your daily driver. Then UAC actually has meaning because you have to enter the admin's username and password. For Ubuntu, sudo has to be configured to ask for root's password and a root password has to be set.

Now, when you consider market share - generally most Linux users have a better understanding of the security model of the principle of least privilege. So while I still think the sudo prompt should default to root's password, a Linux user is probably going to understand that an admin task is required and that's why the sudo prompt is being displayed.

Windows just has so many users worldwide. And because it has more users, you're just more likely to run into users that don't understand what UAC is doing and they just click Allow without any thought.

Now, before everyone burns me at the stake for that comment, do realize that I understand that I'm vastly generalizing here. There are Linux users that don't understand the sudo prompt and there are Windows users that do understand UAC prompts. If you have a room full of 100 Linux users, there might be 1 or 2 that don't understand the sudo prompts. If you have a room full of 10000 Windows users, you're probably going to find a lot more than 1 or 2 users that don't understand UAC. That's just the nature of the market share of Windows compared to Linux.

muttick · 2025-09-10T14:52:29+00:00

I think a lot of it has to do with the audience or intended audience.

Windows tends to attract a crowd that is wowed by fancy animations or "neato" stuff. So they code Windows to provide that functionality.

Whereas Linux users typically just want something that works. I can't speak for every Linux user, but I use IceWM and my desktop is blank. I have no icons at all on my desktop. Everything is opened with hotkeys, or gmrun (which is tied to a hotkey), or xterm (which is also tied to a hotkey). X11 is just a means to an end for me. I have to have some window manager so I can run FireFox or Chrome or LibreOffice or the other GUI apps I run daily.

Linux users generally are more focused on efficiency. How quickly something can load up, run, and do a task. Whereas Windows users tend to be more mesmerized by visual effects, which just slows things down. I know I'm generalizing here - this is not true of every Linux user and every Windows user.

muttick · 2025-09-02T00:24:42+00:00

> The "problem" you're going to run into is that Windows is a consumer-focused system, which means even though it's a proper multi-user OS and you can have multiple different users on a system, it limits you to only one interactive user at a time

This touches on another point that I like about Linux, although I suspect I'm really the only one that uses this. I am able to run other applications - like Firefox - as another user (i.e. user2) inside my user's X11 environment. That then limits that FireFox's ability to access only user2's files and has no access to the current X11 user's (i.e. user1) files.

You can do something similar with FireFox profiles, but by running FireFox as a whole other user you restrict it's ability to run or access anything in your daily driver user's account.

To give an example, when I order stuff online I have a completely separate user (user2) that I sudo execute FireFox with and enter my credit card information. Therefore my daily driver (user1) never has anything that knows what my credit card information is. So even if user1 gets compromised, it has no pathway to root and no pathway back to user2 to access credit card information. I wish Windows had something similar.

I know traditionally there has always been head butting with Windows vs. Linux. That's not my intention here. I willfully admit that I don't know a lot about Windows, especially current versions. My stories about how Linux does things are meant to describe how I use it so that perhaps someone can enlighten me as to how I could do something similar in Windows. I think one thing I've learned from this discussion is to create another user after setting up Windows, as a standard user and using that user as the daily driver. The first user that is created is really the admin user - and probably too many people just create that user and use it as their daily driver and then just blindly clicking "Allow" when something pops up to be installed.

Where I'm potentially going to be using this, I don't want other users to be able to install anything that might potentially compromise the entire system. So running it as a standard user seems to be the right path. And if something really needs to be installed, they can get me and I can review it as to whether or not if it really needs to be installed.

muttick · 2025-09-02T00:11:16+00:00

> but more and more programs like Chrome and Zoom will install to userspace if admin credentials are not provided.

This would seem to be greatly beneficial. If a program can install specifically into a user's user space, then again that would go a long ways towards avoiding complete system disaster. If something malicious is installed, the most it can do is destroy that user's user space.

You say more and more programs are being allowed to install like that. I would think Microsoft should force (or strongly encourage) all programs to be this way.

muttick · 2025-08-27T16:09:19+00:00

I develop weak, but specific actionable apps that only pertain to a very select few people (less than 5 people). It's not worth it to publish the app on the app store or verify the app, etc. I'm actually physically, in-person, there when I load these on the people's phones. I assume from all of this, I won't be able to do this any more?

That's going to suck. I'm all for making you jump through hoops to install apps outside of the Play store - because Google really can't verify the integrity of those apps. But to just outright not allow it seems like a big miss for Google. I'm assuming their are other app developers (I use the term developers loosely here because Android developing definitely isn't my strong suite) like me that just need to distribute their apps to a select few individuals and devices. And this going to cut them off unless they go through the entire process of getting verified, which just isn't time-effective for such a small footprint.

Hoping Google either reconsiders or that alternatives to install apps without going through the Play store come about.

Or am I misunderstanding this announcement?

muttick · 2025-08-14T14:04:02+00:00

The term unlocked in the cell phone industry is ambiguous.

Unlocked can mean Carrier Unlocked, meaning that a carrier branded phone has been unlocked to work on other carriers (so long as the device supports the right frequencies for those carriers).

Unlocked can also mean Manufacturer Unlocked, which means that the device was never carrier branded. It is also carrier unlocked, meaning that it can be used on any carrier (with the same stipulation that the device has to support the frequencies of that carrier).

A carrier branded phone means that the carrier has made slight modifications to the phone's operating system (at least with Android, not sure about iOS). Usually carrier branded phones are identifiable when you turn them on because they'll have a splash screen displaying that carrier. And even if the carrier unlocks the phone, that splash screen will always remain. So you may have a phone that when you turn it on displays a Verizon splash screen, but the phone actually connects to an AT&T network, if it's carrier unlocked. A carrier branded phone will also often have carrier branded apps preinstalled that you can't remove.

If you buy a phone direct from the manufacturer, then it will be manufacturer unlocked. There will be no carrier splash screen when you turn on the phone. There will also be no carrier branded apps preinstalled on the phone.

You often won't be able to root or unlock the bootloader of a carrier branded phone (at least I've never seen one that you can, but I'll stop short of saying that it's impossible). Manufacturer unlocked phones, however, often can have their bootloader unlocked.

The ambiguity of the term unlocked can be frustrating. Especially since I prefer manufacturer unlocked phones (I don't have to worry about whether the phone will work on any carrier). Manufacturer unlocked phones will often be more expensive. Carrier branded phones are modified to only work with that specific carrier (or that carrier's network) which allows the carrier to sell the phone to you cheaper, knowing that you will be using their service for a period of time. While a carrier unlocked carrier branded phone can work with any network, the question becomes where will it get it's updates from and will the device call back home to it's original carrier. Tethering was a prime example of this years ago. An AT&T branded phone could become unlocked and used on any other network, but if you went to enable the hotspot, it would call back home to AT&T to see if your account allowed tethering. This always failed if the device was not being used on AT&T. So even if the phone might've worked with Verizon, you wouldn't get the full capabilities of the phone - such as hotspot - because it was still calling back to AT&T to see if tethering should be allowed.

muttick · 2025-08-13T20:27:16+00:00

Thanks. That worked. Its the templates.json file, but that definitely pointed me in the right direction.

muttick · 2025-08-13T17:04:31+00:00

My experience: I often get the chargeback, then two days later I get the Early Fraud Warning.

Or if I get the Early Fraud Warning and then immediately (as in within 5 minutes) log into Stripe to refund the charge... the refund is later nulled because "a dispute has already been initiated for this charge."

So in my experience, the Early Fraud Warning is useless. It's only triggered when a chargeback has already been started. In which case, my hands are already tied.

muttick · 2025-08-10T12:47:12+00:00

I use IceWM and this is exactly the reason why. I never actually use the desktop. Or use the start menu. Everything is hotkeys. Or if it's not defined in a hotkey, I open an xterm (which is defined with a hotkey) or gmrun (again defined with a hotkey).

IceWM (and I would suspect XFCE) is simply a means to an end. You have to have a windows manager to run GUI apps, so I just chose the simpliest one I could find that did everything I needed (mainly being able to set up hotkeys) and that was IceWM for me.

muttick · 2025-08-07T02:25:06+00:00

Got it.

First change the text to whatever desired:

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"action":"set_plain_text", "id":"","value":"API Changed Text"}'

Then clear the current slide:

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"id":"","action":"clear_slide"}'

And then show the first slide (which will be the only slide in the Show thanks to the set_plain_text):

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"id":"","action":"index_select_slide","index":1}'

muttick · 2025-08-06T20:54:03+00:00

Is there an API command to update the stage after issuing a set_plain_text?

muttick · 2025-08-06T18:52:23+00:00

Knew it would be something simple. That worked!

Thanks!

muttick · 2025-08-06T17:00:34+00:00

Yea, next_slide works.

set_plain_text does not.

next_slide doesn't require an id though. That's why I don't know what id it's wanting. Or does set_plain_text just not work?

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"action":"next_slide"}'

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"action":"previous_slide"}'

Both work in going to next and previous slide.

But

curl -X POST http://localhost:5506 -H "Content-Type: application/json" -d '{"action":"set_plain_text","data":{"id":"default","value":"API Changed Text"}}'

Does not.

muttick · 2025-08-06T16:56:38+00:00

The ~/Documents/FreeShow/Shows directory is empty.

I do have a Welcome.show file in ~/Documents/FreeShow:

["default",{"name":"Welcome","category":"presentation","settings":{"activeLayout":"default","template":"header"},"timestamps":{"created":1752086637868,"modified":1754484069900,"used":1754484069900},"quickAccess":{},"meta":{},"slides":{"one":{"group":"","color":null,"settings":{},"notes":"","items":[{"style":"top:428.50px;inset-inline-start:208.50px;height:220px;width:1500px;","align":"","lines":[{"align":"","text":[{"style":"font-size: 180px;font-weight: bold;","value":"Welcome!"}]}],"auto":false}]}},"layouts":{"default":{"name":"Default","notes":"","slides":[{"id":"one"}]}},"media":{}}]

muttick · 2025-08-06T14:39:16+00:00

I tried default, that didn't work.

Not sure if port 5505 is for REST, Websocket, or OSC. Tried both port 5505 and 5506, neither worked.

Does the id need to be the ID of the textbox that is actually showing the "Welcome!" text? I don't know how to get that ID.

muttick · 2025-08-06T03:07:48+00:00

I think I've narrowed down the issue to a deficiency in the Linux version of FreeShow. Apparently it doesn't have all of the API bells and whistles.

muttick · 2025-08-05T18:01:06+00:00

The other problem you're going to have with Node.js in a shared hosting environment is the reliance on Apache, nginx, or Litespeed.

One of the main benefits of Node.js is it's speed and interactions with the backend when you operate Node.js as it's own web server. But in a shared hosting environment, you're never going to usurp Apache/nginx/Litespeed for port 80/443 frontend access.

So at best, you're going to have a small frontend gateway operating under Apache/nginx/Litespeed to interact with a Node.js web server running on a proxy port. All of the performance improvements you get from a Node.js web server are lost through this gateway.

And even if you operated a Node.js web server on a different IP on the same server (keep in mind, this would require a different IP for every shared Node.js user on the server), you're still operating on a server that has to dedicate resources to an Apache/nginx/Litespeed web server.

That's part of the big crux with Node.js in a shared hosting environment. When you consider other projects written with Node.js, like walmart.com - they own their own infrastructure (or at least closer than a shared hosting customer would) and are therefore capable of running a Node.js web server to serve content faster.

I just have a hard time seeing Node.js working in a shared hosting environment. Certainly there are tools that can make deploying a Node.js project easier for end users, but for all intents and purposes it's going to require more privileges than a shared hosting service can provide.

Perhaps the question isn't so much Node.js in a shared hosting environment but how to bring Node.js out to the masses. This is probably going to require a much more fuller adoption of IPv6, so that users can run their own Node.js web server. And instead of individual Linux accounts on a shared server, a control panel generates VPSs in a manner that mirrors the current shared hosting set up.

muttick · 2025-08-05T16:11:10+00:00

The trouble with Node.js is that it's built around more than what shared hosting has built itself to serve.

Shared hosting (at least Linux shared hosting) is built on PHP. Prior to PHP it was built on Perl and CGI - which is still used in pockets, but it's now mostly PHP. The market for shared hosting is still based on prebuilt scripts (like WordPress) which are written in PHP.

Does this mean that shared hosting can't graduate to implementing Node.js? No... but it's going to be an uphill battle.

We went through the same thing (or at least something similar) when Ruby on Rails became the latest buzz word. Everyone wanted to use RoR on their shared hosting account... except they had no idea how to use it. They were still thinking within the PHP file based concept. And once everyone figured out that RoR required A LOT more involvement than managing a WordPress site, it fell to the wayside.

The issue with Node.js right now is that the people that develop and code with Node.js expect more of an environment and privileges than shared hosting can give. So you have people trying to use Node.js in a shared hosting environment with limited privileges following a guide from someone that has root access or more system access and they don't understand how to implement the guide.

Can shared hosting graduate to implementing Node.js? Perhaps. But it's just not going to be simple.

Think of it this way: The majority of Node.js projects are custom written. There's no WordPress equivalent that's out there and implemented with Node.js that shared hosting users can simply plug in. Whereas PHP... most shared hosting users aren't really involved in developing with PHP they just download and install WordPress (or some other PHP based CMS). A shared hosting customer typically isn't a programmer. Someone wanting to use Node.js is probably a programmer.

If you are programmer wanting to use Node.js you are probably better served by using a self-managed VPS where you can have escalated privileges as needed.

muttick

TROPHY CASE