Have a great New Year.

There is a presentation on the Mosh site. The speaker knows the project and is probably the project owner or lead developer. I’m not certain. He tells the audience about what is wrong with standard terminal sessions and how they developed this mobile communication protocol that rides somewhere between the various layers of SSH and so on. Since the website touts that they are more secure… by inheritance they are as strong as the weakest link but this was an earlier argument.

Then he talks about predictive local echo. The idea here is that in a normal terminal session your keystrokes are not actually echoed on the terminal (unless you have local echo turned on) but represent the output of the server application whether it is a command shell, editor, curses app, or something else. Predictive local echo will echo the character to the local console with the expectation that 70% of the text is echoed by the server anyway… and then the PEL will clean things up.

Well, there are a number of problems with this. The first is that PEL really only works in the shell itself. Once you are in vi and changing modes it is impossible to echo properly… and that is why most terminal emulators default to local echo off. Many old-school applications screen scrape terminal sessions and would not be capable of dealing with PEL as it does not effect the byte stream so much as it does the representation in the terminal window. The demo that was presented was a command shell which is the easiest use-case but is by no means proof or substantive.

Next the presenter tweaks Google for doing an adequate job with mobile applications in that Gmail echos to the console. This argument also misrepresents the domain of webapps, network capable apps, and probably MIT’s position on computing all in one statement. SSP is not going to help Gmail be a better app. SSP is not going to make my mobile browser better as I leave my home’s hotspot and head into the wilds of 3G/4G. Re-establishing my mobile session is no different than any network disaster recovery plan within the enterprise.

The only thing that might be interesting about SSP is that the important bits about the connection are being moved from one layer of the OSI to another. (I do not know which is which anymore).

**I went back to the Mosh site to get some more details. Sure Mosh is all about the shell but what about the app? They state that the Mosh server is actually a terminal emulator of sorts and that’s how they get the delta of screen changes to the local console. It’s not until version 1.3 that they implement larger screen buffers… meaning that you’re back to tmux or screen for that.

The big issue for me is the firewall issue plus UDP plus roaming connections. This makes hijacking or sniffing more likely once you break the encryption. And if you can get past all that… it only solves one use-case.

It is mostly an uncensored response to my environment, things I’ve read, or mental exercises.

As a Bag of Crap goes I’m still hoping not to waste anyones time… but it’s certainly not a seed for what I write about here. I hope you’ll join me anyway.

PS: That includes not naming functions, variables or classes with “error” in the name.

Logging best practice

plug in your electric car

If you are the owner of the car in the picture then you are not likely to be paying anything. This is a pseudo public space but I’m certain that the property owner was not expecting to have to burden the cost of charging every electric car out there. And I’m certain that homeowners are not interested in replacing all of their receptacles with secure alternatives.

Coincidentally Google announces Dart 1.0, Firefox announces Rust 0.4, Google’s GO is making headway … but most telling is the article, I read today, criticizing FogBugz for implementing their cornerstone application using a proprietary and internal language and toolchain (Wasabi which looks like VB).

So my intuition tells me that if Oracle does not make some serious corrections “we” are about to experience a paradigm shift akin to the magnetic swap that the mad scientists have been talking about for the last 10 years; because:

• business owners need to reduce their risk – general security and maintain control of the API
• increase their intellectual property – proprietary toolchains would add some value if they work
• reduce programmer turnover – in a way proprietary languages will not actually enhance individual marketability (of course you have to get them first)

But if you cannot afford to design and implement a first class programming language… then you’re forced to develop a DSL. And if you cannot afford that… then you have to use someone else’s or something that is open source and liberal (nothing with the GPL; stick to MIT, BSD, and a few others)

In conclusion, and I hope I have connected the dots, there will be a major fracture. A small portion of the developers and businesses are going to go for the 100% commercial toolchain like Objective-C, iOS, .CLR/.NET and then there is going to be another group that is going to go completely open source as in perl, python, ruby, GCC, GO, Dart, Rust, and internal DSLs.

• javascript is interesting but will be killed along with the JDK
• Java might fork with a reasonable replacement but the devs working on the commercial version, who are responsible for the current state of affairs might poison the same tree.

Sadly, Google’s current price drop might have something to do with the Java security issues as it was recently reporting that Android had it’s own security issues.

It’s clearly a sad state of the industry. It feels like a huge grey cloud overhead. I hope it’s just a little rain and not a flood.

(a) there was a time when your social security number was truly secret. Now everyone from the cable company, ISP, newspaper boy, lawn service, High School, University, hospital and doctor wants your SSN and we give it freely and without challenge. Who really knows why a doctor or newspaper delivery service needs my SSN. Are they going to sue me into and after I’m buried? In Sweden the SSN is sacred; I’m just not sure how they get around the problems we have. (could be functional and/or legal)

(b) There is no privacy on the internet. Whether your using any of the big name browsers, you never login, you always use other people’s computers or cyber cafes. The challenge is that between the ISP, browser manufacturers, super/affiliate advertisers, search engines; they where where you have been and where you are going. Not even the like of TOR is going to save you. Same goes for the anonymous breadcrumbs you thing you are dropping. They will always lead “them” back to you.

In a side note. If you’ve ever seen or purchased from one of those “as seen on tv” infomercials. The deals are great. Essentially you pay for shipping which costs them much either, however, it does offset their costs somewhat. The “play” for these companies is to get you to buy something. Anything.  This way they capture you personal information which they will resell at a profit. This is how all of these marketing machines work. One interesting thing… I have never experienced an increase in the amount of spam I receive. Hmmm.

Another side note. Over the last 18 to 36 months there have been some data breaches amounting to tens or hundreds of millions of credit card numbers and personal information. So why haven’t more people been complaining about credit card fraud? Why haven’t news programs done additional reporting? I wonder if we’re being marketed to because the credit card infrastructure is just not that sophisticated.

1. There is no such thing as email privacy.
2. Most email travels through the internet from point to point in the clear
3. So called legalese on the email footer about intended recipient and communication has not been tested in court and it not binding.

That said, if you have a private email server that you think is secure and you use it exclusively because you want secure email that is not to be seen by the prying eyes of big brother or even Google, Yahoo, Hotmail, Facebook or other… then you are sadly mistaken and misinformed.

Just because you have an uber secure email server does not mean that the recipient has the same. So then the real question becomes… Why not use Gmail yourself?

However, there is one thing that I have to remind myself of. “Trusted Source”. With that recent Russian malware scare I can only imagine that the internet scale is going to slow and that sandboxing and trusted source are going to be required. For that matter I have already started to adjust to a Microsoft desktop at work and in my VMWare at home.

And of course if it’s a hoax … then I wish a thousand papercuts on the perpetrator.

PS: I’d rather be using OpenBSD!!!

Design

(1) You need to decide what exactly you hope to get out of a logging session. Are you going to be debugging bugs, crashes, or other critical events like a forensic accountant or like a whack-a-mole?

(2) Are you going to use flat files, how big will they get, how many files will you keep around? All very important when thinking about backups, disk space, maintenance, recovery, and so on. You might also be thinking about the different versions of syslog-like tools where you can ship the events remotely.

(3) Are you going to store the logs in a DB on the local system and then use sharding to allow for more permanent maintenance? This is interesting because the searching can be easier than grep, awk, etc… Also, considering (4) grouping related messages is easier and you can use SQL-like reporting tools.

(4) Are there some pre-optimizations you want to perform like all logged entries are stored in temp storage until the transaction is complete. Then the data is shipped to the repository for storage.

Good Practice

Treat all of your code the same.  Whatever level of logging you are performing you should be consistant throughout your application. This way you will not be surprised by your results and you will not have to worry about “and then a miracle occurred)

What to Say, Where to Say it

If you are processing transactions then make sure that you create a transaction ID as soon as possible and start using that ID with every log message related to this transaction. This is necessary so that you have a thru-line and so the transaction can be traced.

Also make sure that you are clear as to the intent of the function and what the results were. That also means that the type of entry should make sense. INFO, WARN, ERROR, EXCEPTION and so on.

You might even time the execution of the function.

Warning

One thing to be wary of. Logging can consume your disk, disk I/O, CPU, memory, message queues, database. You can spend more time copying, moving, and filtering your messages that it might effect the ability to produce meaningful results.

For example, using a Redis pub/sub in order to log transactions might seem like a good idea, however, if you consume all of system memory you may end up swapping and then net result is going to be poor performance.