Skip to main content

Posts

Showing posts from 2017

Dear HP, Canon, Lexmark, Brother - fix your printer drivers

I don't do a lot of printing (but I currently own four printers...). When I do print things on paper, I expect things to work. Unfortunately, none of the major brands of printers out there actually work on Linux over Samba network shares to Windows with any reasonable measure of consistency. It is, however, a reasonable expectation that such things work out-of-the-box. Trust me, I've tried and I give up. My current solution is to use the free version of this software: VirtualHere USB over IP I currently have to SSH into the Linux box, start up VirtualHere server, run the VirtualHere client on my Windows machine, attach the printer I want to connect "locally", and pray that it works without any issues. Unlike Samba, which didn't work at all, doing all of that generally works but sometimes I'll have to reinstall the printer drivers because attaching a device to a major OS is apparently too much to ask for. Two of my printers come with a WiFi hub buil

I, um, broke stuff

While I had a lot of fun putting that comic panel together, I'm not planning on getting into the webcomic business. I keep getting told to "keep my day job" as if I'm not hilarious or something. The comic does provide a nice lead-in to a more serious topic whereby firewalls are able to be circumvented in unusual, hard to detect ways. This story begins with "needing" the ability to connect two clients together. Since I don't generally operate in web browser land, I'm not constrained to whatever features are only available in a web browser. Since that's not a restriction, I could use whatever protocol I came up with/wanted to use. Since ports 80 and 443 are most commonly accessible through even the craziest of firewall setups and I had previous experience writing my own HTTP and WebSocket clients and servers, I knew very well how those protocols worked. My main issue with just using WebSocket is that it transitions into a framing protocol

What is wrong with European/German law?!

About two to three times per month, some random business in Europe will come out of the woodwork and e-mail me wanting to use one of my open source software products and say something to the effect of: Please send me a quote, an agreement, or contract in order to use [open source software product XYZ]. It's open source under an open source software license. In the case of open source CubicleSoft software, I generally offer TWO licenses that you can choose from! Every time I see that type of silly e-mail, I'm reminded of a joke article I read a long time about shooting oneself in the foot with various programming languages that started off with C: You shoot yourself in the foot. And ultimately devolved into 370 JCL: You send your foot down to MIS with a 4000-page document explaining how you want it to be shot. Three years later, your foot comes back having been deep-fried in duck fat. Trying to communicate that open source software is open source to a business tha

Running cron scripts every minute is a waste of system resources

If you've ever done this in a crontab file to handle a user-initiated event that rarely happens: * * * * * /path/to/script Then you are definitely doing it wrong. I know I'm guilty of doing that but only because until recently I didn't have a viable solution for the problem. That type of cron line is lazy and running a script every single minute for a process that only happens on rare occasions is pretty wasteful of system resources. A much better solution is to use either Cloud Storage Server /scripts or /feeds (or both) with their associated SDKs. I've been using both options on production systems for a while now and they provide several significant benefits over traditional cron: The script is only run when there is something to do. The SDK makes the API call to Cloud Storage Server, which, in turn, kicks off the process. The ability to safely pass information to the target process without requiring intermediate file storage. Users don't have to w

How to stop marketing spam dead in its tracks

Occasionally, I'll get e-mail marketing messages directed at my business from other businesses. Most of the time I'll just hit delete and I never hear from them again. However, I'll occasionally run into a REALLY persistent entity out there that drops their useless marketing in my in-box daily and also tries to get personal to the point that it is creepy. If their company has a U.S.-based address anywhere, then they are in violation of CAN-SPAM U.S. Federal law, which requires an existing business relationship to initiate contact. All other contact is subject to a maximum $40,654 USD fine per message as per the Federal Trade Commission's website. Here is what I send to the obnoxious, persistent entities: "As per CAN-SPAM U.S. Federal regulations, remove all @domaingoeshere.com addresses from your contact list immediately and stop abusing my system resources. You do NOT have an established business relationship with me. Any further contact will be construe

Mozilla Send's archnemesis is Cool File Transfer

On Tuesday, August 1, 2017, CubicleSoft announced the release of jQuery Fancy File Uploader . Then on Thursday, August 3, 2017, the announcement of Mozilla Send reached Slashdot . Over this past weekend, CubicleSoft responded to the challenge and built a better solution called Cool File Transfer: Check out the Cool File Transfer GitHub repository Cool File Transfer is better since it skips the intermediate file storage on a third-party system and therefore can perform unlimited data transfers. If /tmp is a RAM drive, then nothing ever hits the disk! (Utilizing temporary file system storage is how PHP handles all file uploads.) There's no file size limit, it is easily hosted on internal, higher-performance and trusted infrastructure (e.g. an Intranet on gigabit Ethernet), recipients don't have to be running modern browsers, and it just plain works. Woo! Done and done. Mozilla, now that just one software developer has completely crushed your latest project, pleas

An alternative, better approach for writing technical documentation

Technical documentation for a software project is a complex topic. I've seen all sorts of approaches throughout the years and implemented many of them myself. I've seen everything from a "no documentation found here" approach to using a Wiki to hundreds upon hundreds of pages in a PDF (or other specialized format like CHM) that no one really reads. In addition, technical documentation almost never mirrors reality. The source code is always the definitive authority on what happens. Technical documentation is mostly an afterthought, "Oh, yeah, I guess I better document that thing I wrote." Most users of software can't be bothered to read the source code OR the source code is proprietary and only available in binary form or remote means (e.g. a REST API). Users want something more human-readable than source code to look at anyway even if the source code is definitive and, in many cases, more readable than the technical documentation. First I want

The Star Trek stardate for a better UNIX timestamp

A large body of software will break in unusual ways on January 19, 2038. This is known as the UNIX 32-bit timestamp bug. However, UNIX-style timestamps are used in all OSes, so it is a global phenomenon and a poorly designed software defect. 64-bit timestamps merely extend the problems presented by 32-bit timestamps to identify what day it is (i.e. what the end-user actually cares about). Perhaps there is a better timestamp we should have been using all along: Star Trek stardates. Formal representations: 32-bit: 1 sign bit + 14 bit "day" + 17 bit percentage 64-bit: 1 sign bit + 31 bit "day" + 32 bit percentage If we were using Star Trek-style stardates for date/time storage, our timestamps would have better precision and the upcoming 32-bit software problems would have happened early 2014 instead of waiting until 2038 for the breakages to happen. That is, force the people who created the problem to clean up their mess instead of letting them retire an

Secure web server permissions that just work

I have been doing web development since, well, web development basically began. And I've used a wide range of hosts. Since I don't see anyone stating answers succinctly and definitively anywhere, it is time to write a solution to the question on everyone's mind: What are the permissions that I should set for web server directories and files? The first step is to identify the user that the web server will access files with/run under. For example, many Linux distributions set up 'www-data' as the user. I'll be focusing mostly on Linux as it powers about 66% of the Interwebs, but Windows Server users can benefit too. It is important to get your setup correct from the very beginning. Propagating permissions down the website tree as new directories and files are created is critical to maintaining sanity. Knowing who created a specific file or directory is also important when working in a team. As always, if you can't trust other users who might have a

DNS cache spoofing/poisoning is useful for web developers

When most people hear the word "poison" they immediately conjure up bad things in their mind from some weird crime drama that they watch on TV. DNS cache poisoning (or spoofing) is generally considered a bad thing because it means that a domain name is resolved to the "wrong" IP address. It is usually used in terms of an attacker that gains access to a DNS host to deliver the wrong responses to DNS requests or intercepts and alters responses to requests, which then points the client at the wrong IP address. DNS cache poisoning, however, can be used for a few positive, legitimate things. Let's say you want to relaunch a website on a different web host. To do this, you could develop it locally and then upload the files when you are finished to the new host and switch DNS over and watch it break spectacularly. But if you want to get a relaunch 95% right, you need to see the new website before DNS is switched over. To do this, DNS cache poisoning comes to th

WTFPL is harmful to software developers

Occasionally, I run into a piece of software that utilizes an inappropriate license with a crude title. Today I want to talk about one of those licenses. It is called the WTFPL and it is harmful to any software developer that uses it. I don't use foul language even among impolite company, so I'm not going to copy the license text here. You can read it if you want but it isn't necessary. There are about 300,000 words in the English language at any given time. Of those, about 200 words are considered to be rude, crude, foul, and generally inappropriate to use in most settings. The words a person chooses to use in casual conversation says a lot about them. Language issues aside, the basic gist of the WTFPL license says that you can do whatever you want with the software that the license is associated with. If you look at a traditional software license (aka EULA) with its many pages of text and the various "license wars" out there, the idea behind the WTFP