OliverJones

Oh man, this brings back the days when I wrote special debug-version malloc and free code to try to track down heap corruption due to malloc / free misuse (in code I had contributed to). Stuff like kbyte-long boundary buffers with bit patterns in them, and all sorts of lookaside lists run in parallel with libc's default code. Those bug-detectors worked OK. Hard-nosed code inspection worked far better.

As an old-timer in writing code, I think my generation's most-challenging legacies (=== the things we f**ked up) are the non-robust malloc/free concept and null-terminated text strings. Bugs in code using those conventions have been exploitable to a really damaging extent. I learned to program in C from K&R. And getting data-structure code right, and safe to deploy, in that language and its derivatives is HARD.

The C inventors are (were in Dennis Ritchie's case) brilliant and Bell Labs was great. Their ideas shaped the the stuff the global internet runs on. But these parts of what thy invented ..... ouch. (All OSs had the same problems.)

I wish the wonderful article presented here carried a more prominent warning about this. Many will read it as they learn to code. The history of our profession can teach about what NOT to do as well as what to do.

I'm working on comparisons between redis and SQLite for object caching. So far things look favorable.

I did this project for WordPress, because object caching helps performance (and therefore carbon footprint) a lot and cheezy hosting services don't offer redis. But most of them have SQLite.

Oddly enough, SQLite is really slow on the one BSD hosting service I've tried.

The clustered primary key (NO ROWID) setup that came in with SQLite version 3.8.2 (2013-12-06) makes it very fast indeed when used for a large persistent key-value store.

And later improvements have just continue to accrue.

This from a guy who just implemented a persistent object cache with it, and was blown away by how well it works. And my requirement was all SQLite versions 3.7 and later, so there's conditional code. (ROWID or not, UPSERT or not).

Not to mention there are probably ten or more of these databases in your mobile phone. We haven't heard, at least I haven't, about any monstrous day-1 vulnerabilities in this code.

A really good design choice, SQLite is, if your application can live with its local file system requirement.

I went with SecureCRT because it had its own well-done terminal emulator back in the mid-1990s when I started using it. It's evolved nicely ever since.

OpenSSH is indeed widely used. But the only game in town they're not. There are commercial SSH implementations that aren't based on OpenSSH, reasonably widely used too. For decades I've used a Windows product called SecureCRT based on their own ssh and sshd stacks at Van Dyke. I'm sure there are others too. (I hated putty's UI.)

There's an obvious infosec observation here. Different stacks, different hacks. Maybe individual infosec people should adopt a randomly chosen stack from among the less popular. Then the dreaded zero-day that hits the most popular stack won't cut off their access entirely.

I have to say, I understood what this is really fast when I saw the README. It's really a great idea. I'dve been all over it before I :-) :-) retired.

It's going to save growing companies a fortune, by helping cancel promptly unused money-sucking accounts across the SaaS multiverses.

I just hope it's easy to use for superbusy founders, tech people now riding a success wave. Because those are often the people who do the account-cleanup job. If this tool is a pain in the *s to use, there's even more time down the hopper.

It's almost impossible for people like us to teach ourselves to delegate by inflicting pain on ourselves. And saving big money is worth some pain, amirite? Been there. Done that.

But HERE's an incentive to delegate:

* grab the most talented devops person you know. * tell them about this open-source project * delegate to them this account-cleanup PITA * invite them to donate time to the open-source project and give them time to do so. * but they still have to do the actual cleanup regularly. * stand back and watch the growth of a REALLY USABLE open source money-leak-hunting project.

Every single YCombinator portfolio company would benefit from this. You VC guys? Get some really smart interns to work on this too.

My experience of this is interesting.

When I'm writing code I care a lot about, I don't have to worry about DRY stuff, because I can't really write the code without figuring out the right abstractions. It starts DRY.

But when I'm cranking out reporting code or boilerplate of some kind and I just want to finish the job, my work starts out dripping wet copypasta. I test it. I then do some squeezing -- refactoring -- to unify some of the abstractions and delete the almost-dup code. I try to DRY it up to a reasonable level. But, I confess, I don't subject the abstractions to as much scrutiny as the code I care about. My successors probably hate me for that. But...

I'm certainly not crying "Woe is me." Not at all. SVB, and other parts of the business, worked out very well indeed for us and our employees. Did scramble to make payroll a couple of times, but that was nothing to do with SVB. Why did we scramble to make payroll? Because employees, including founders, needed to feed our families etc. And, yeah, laws against stealing wages and all that. Basic honesty in business sometimes means taking personal risks.

An investor / board member back then said "don't worry about it" when I brought up FDIC coverage limits upon their advice to dump the money at SVB.

At any rate last Sunday the FDIC knuckled under to pressure from the Sand Hill Road folks and extended their insurance to all deposits, not just the first quarter megabuck owed to each depositor. SVB's shareholders are wiped out, and maybe some non-depositor people they owe money to will take a haircut. But the various startups will be OK.

Regulatory capture, it's called. Man, it does a lot of damage.

Long ago I and colleagues opened accounts at SVB for two different outfits with VC money. It was simply the thing to do when getting started converting that money into software that would then produce lots more money.

It was simply the thing to do. We didn't have CFOs. We knew darn well our deposits would exceed the household-banking FDIC insurance limit. It would have seemed a brutal waste of very precious time to do an independent background check on our banks.

Look, friends, the rule of law is what makes it possible to do business. If we lowly startup entrepreneurs can't trust institutions like banks reliably to provide their services, and we can't trust the government to do their part in maintaining that reliability, who can we trust? Are the next YC classes going to get their financing in Krugerrand gold coins? Are they going to need to look for safes on EBay along with the other gear they need to make the magic happen?

Lowly? Yeah. Compared to banks, governments, infosec certification people, even landlords and vendors? Yeah. Lowly. We have to be able to trust our environment at least a little bit to succeed.

This regulatory capture is freakin' ridiculous and has to come to an end.

Dredging up my old college math. A mathematician named Kantor proved that the number of rational numbers (fractions) of postive integers is the same as the number of positive integers. His proof involves COUNTING the fractions. And that kind of infinity is called, well, countable or aleph sub(0). It's like O(n) in algorithms. And in that world O(polynomial) and O(n) are both countable.

But our favorite transcendental numbers, you know them, pi, e, psi, that lot, are not part of that. Neither are multiples, or fractions, of those numbers. There's an uncountable infinity as well, holding them, and it's strictly larger than countable infinity. Maybe that what Walt Whitman was thinking when he wrote "I contain multitudes"?

At any rate, possible physical distances are uncountable. Yup. There's more of them than there are of integers. And living things with brains have a (probably) countable number of neuronal interconnections, each of which depends on uncountable physical distances.

(We know this in the computer industry: we have all sorts of hardware and software that quantizes the physical stuff going on in chips and conductors to extract bits -- to make the uncountable countable.)

My question: is this digital infinity countably infinite? Or does it go beyond that?

Do people who model -- information-theorically -- living brains and the minds they hold consider this issue? Does this countability matter to our understanding?

tl;dr referers from web server logs.

Simple is sometimes best. And, ya know what, you don't need to spend a lot of money or time in the complex surveillance economy to look at your logs for bigco.zoom.us and that kind of referers.

I've spent a good chunk of a half-century-long career, now winding down, doing the kind of work our author describes. Most of it was on my own initiative. I'd notice some kind of anomaly in the logs of whatever app I was working on, investigate it, and generate a report program highlighting it.

Most of the time people ignored this stuff. That took some getting used to.

But occasionally one of these little report programs would show a solvable problem. The usual example was a whole bunch of customers using the app in some way unpredicted by product designers and developers, and so missing out on a valuable feature of the app. Often we were able to add some kind of workflow feature, or add a UI afffordance to help customers take advantage of existing features.

(Other times the little reports detected performance trouble. Always consider using time-of-week as an x-axis when working on these little reports.)

The hard thing about doing all this is that I, and my colleagues, never knew ahead of time which data anomalies would be actionable and which were just fun facts to know and tell.

Sometime along the way, that part of my work was dubbed "data science". That's about the same time a bunch of enterprisey software entrepreneurs discovered that "dashboards" generate sales because they appeal to front-office folks with control over money. Irony: I developed a bunch of integrations for a really expensive data-analysis product using Jetbrains tools I paid for personally.

I always thought of that part of my jobs as diagnostic and exploratory. What can we learn from how this system works in the real world?

In my case, of course, I also had some responsibility for the systems generating the data I analyzed.

My advice to others doing this:

1. Always always assume you'll be called on to generate recurring reports with your little report programs. Make or buy a report-generating tool that can, at a minimum, deliver CSV files by email.

1. Indulge your curiosity. Especially with strange and incomplete data sets. Don't think of your task as "generating a report from bogus data for people who don't give a s**". Think of it as "figuring out how to make sense of the process from the data it captures as it operates".

2. Learn all you can about the processes you're analyzing, be they failed logins to SaaS apps or ambulance-calls to wrong addresses, or whatever.

2. When you have nothing much left to learn at a particular employer, teach somebody else how to do your job and then move on.

My brother the academic librarian / archivist has, for many years, been warning about this kind of obsolescence. It's necessary for we software folk to ask ourselves "two centuries from now, how will people make sense of our digital files?"

One of the challenges is, of course, that it isn't obvious to any generation of creators what will be of lasting value.

Academic archivists and MLS degree holders can't do it all, any more than they could control the 19th-century paper factories that churned out all that junk paper that turned brittle in a few decades.

Script kiddies doing vuln probes. Definitely not worth much of your energy to try to figure out root causes. For what it's worth, if you activate the Akismet plugin that comes with WordPress, you'll get Automattic's crowdsourced spam-comment detector and almost none of this kind of rubbish will get through.

WordPress also has an xml-rpc feature, originally set up to allow a thing called a "pingback". That's a way of inserting a comment on your blog post if I mention its URL on my blog post. An attempt at community-building, it was. But very vulnerable to scripting attacks. There are plugins to control (restrict) that functionality.

I worked for a B2B SaaS outfit which charged by month by seat. Some customers demanded usage-based charges and our sales and PM said yes, without checking in with dev.

As the guy who knew the app's logs best, it fell to me to code up and then maintain the monthly report to generate those customers' usage data and send it to billing. (The things we do for love.)

Our app's log data wasn't complete and predictable enough to generate completely accurate usage data, so some assumptions were needed. (The problem was sometimes-missing timestamps for "usage session complete". Yeah I know, WTF? I inherited that code.)

Things got a tiny bit ugly. Customers -- whales of course -- started demanding weekly, then daily, usage reports. They demanded backing data for their bills. And, it became really hard to actually fix the defects in the app's logging so it was possible to generate accurate usage -- it would change the billing too much, and we'd have to explain it to the customer. It was a pain in the you-know-what. Especially for a guy like me who prefers to write really accurate software where other peoples' money is involved. This didn't threaten the business, it wasn't nearly that serious. But, wowee, it was unpleasant.

Lesson: If you're going to add a new SaaS pricing model to an existing service, think of it as a BIG change. Make sure you can capture accurate and commercially defensible metrics for your pricing model. Get devs to think it through. Get testfolk to think it through and work out some system tests. Sales people, don't just tell customers they can have their own pricing model, but only if they sign up by the end of the quarter.

A weight discrepancy of ten to fifteen TONS????

That's no small mistake. It's not a rounding error on the weight of the soda cans loaded into the galley for the flight.

That's most of the passengers. It's most of the freight. It's heavy enough to be a spare engine in the hold. It's a goodsize fraction of the fuel needed to fly from Seattle to Honolulu. It's certainly enough to foul up the mandatory weight-and-balance computation the pilot in command is required to do.

Somehow the input to this software package missed something big. It would be interesting to know exactly what was missed.

I sailed on that fine ship several times, before the Boeing 707 era, as a little kid. My dad was a junior diplomat at the time and so he and his family traveled "cabin class". The classes were "first", "cabin", and "tourist".

It was four and a half days from New York to Southampton.

It was some kind of fun for an inquisitive 8-year-old boy. I think I drove my parents crazy by roaming all over the place, getting into every space I could. (The engine rooms weren't accessible, but the guy in the radio room was great.)

One crossing, eastbound, was in the dead of winter, late January. Me and my brothers were in bunks pretending to sleep in a cabin fairly near the water line (cabin class, right?) with one of those circular portholes. A crew member knocked on the door, and walked in with a steel plate and four big bolts. She proceeded to bolt the plate over the porthole. She said, "storm coming, boys" and moved on to the next cabin.

Now that was a storm. The kitchen was closed (no hot food) for a whole day. It felt like we were rolling 30 degrees. I'm sure it wasn't but it sure felt that way.

The ship only lost four hours off her schedule for that voyage; she had to head upwind for an hour or two in the worst of the storm. They don't make passenger ships like that any more. But the North Atlantic ocean in winter is still that dangerous.

Once the 707 was available, junior diplomats didn't get to travel by ship any more. Faster, but much less of an adventure.

Good. Invent things. Try things.

But keep this in mind: plants evolved lignin to make their structures (trunks, branches, all that) hundreds of millions of years before bacteria and other microorganisms evolved the ability to break down that lignin. So, for hundreds of millions of years, plants captured carbon dioxide by photosynthesis and sequestered it. That's what changed earth's atmosphere from reducing to oxidizing. Fossil carbon is the geological remains of that carbon capture.

It's hard to imagine carbon-capture tech that has the longevity of those planet-wide lignin forests.

The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts.

This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.

HEY! Before you adopt this check the bandwidth egress costs! Seriously.

Your disaster recovery plan will need to budget for extra egress costs if you ever need to restore something big from one of those virtual tapes. AWS charges for egress -- downbound -- bandwidth but they don't charge for ingress -- upbound -- bandwidth.

(And I think it's funny their icons and images look like old school DECTapes.)

With respect, calibrating compass compensations is in fact very important in FAA approved aircraft. It's part of the inspection checklist signed off by the licensed mechanic.

My flight instructor once switched off the electricity to the airplane's controls and radios and told me to land. At an airport with a control tower. Using the magnetic compass, airspeed, barometric altimeter, RPMs, that's it. Nothing else works without electric power. There's a whole procedure for doing all that. Being able to navigate safely with an old-school magnetic compass is life-critical.

And I thought a four-hour flight I once took in a 172 was far too long!

Good little airplanes, they are.

I suppose they chose their engine airspeed to achieve the lowest fuel consumption rate https://www.se.edu/aviation/wp-content/uploads/sites/4/2020/... See pdf page 132, book page 5-18. It looks like they could use as little as ~6 gallons/hour at 1900 rpm. You can save a lot of fuel by flying more slowly; handy to know if you need (heaven forbid) to stretch that 45-minute reserve when your destination is socked in.

It's not quick money, but writing books can generate an ongoing royalty stream. And, they're good resume builders if you want to do freelance work. It worked for me.

You can do worse than O'Reilly Media. https://www.oreilly.com/work-with-us.html

And there are other publishers.

The internet has this kind of stuff too. Addresses "reserved for documentation" by IANA / IETF. I don't remember seeing them mentioned on-screen. I guess it's easy enough to register ghostbusters (dot) info or whatever.

example.com https://datatracker.ietf.org/doc/rfc2606/ 192.0.2.55 https://datatracker.ietf.org/doc/rfc5737/

There must be layers upon layers of old special-case routing code in telco switches that makes it really hard to just start issuing those old 555 directory numbers to subscribers.

Interesting. Honda's core competency has long been internal combustion engines (ICE). My household has, for a long time, had a Honda car, motor scooter (110cc), and lawnmower. We don't need a generator, but if we did we would pick Honda. I was an early adopter of their Insight hybrid car, almost a quarter-century ago. That was focused on battery support for a very light ICE, not on replacing the ICE. It was effective.

I've long believed they were all in on hydrogen fuel as the next big thing, because it would preserve their internal combustion tech investment. And, I've long believed that was an existential mistake. They, working with Toyota, could have pulled it off by pouring bucketloads of upfront capital into refueling infrastructure (like Tesla did with their Supercharger network). But they didn't. Pilot projects with short-range delivery vans don't cut it.

It's about time they started working on BEV.

But: pedals? pedals with ergonomic problems? (No seat height adjustment is evident and they're far too widely spaced to let a rider get any power without rocking back and forth.)

There are plenty of decent e-bikes in this market space. Most of them leverage the existing cycling parts and service capabilities . Honda's coming late to this party.

We shall see.

A long time ago -- late 1980s -- I worked in system software, VMS-based, at DEC.

Sometimes we used, for dev and testing, dedicated machines running with clocks set 20-25 years in the future. (They was a measurable investment of capital, power, and cooling back then.) This was smart: the remnants of DEC were able to sidestep the whole Y2K cluster**k.

Are our key tech vendors doing the same now? It's about a quarter century until the 2038 fin-de-siecle. I sure would like some assurance that the OSs, DBMSs, file systems, and other stuff we all adopt today will have some chance of surviving past 2038-01-19.

I know redefining time_t with 64 bits "solves" the problem. But only if it gets done everywhere. Anybody who's been writing programs for more than about 604 800 seconds has either thought through this problem or hasn't.

Some random observations from an old-timer developer.

1. This excellent article is all about UML's class modeling capabilities. UML has other useful capabilities.

2. Sequence diagrams are very useful. I've created plenty to document and teach complex interactions between various (micro-) services. But it simply never occurred to me that I would generate code from sequence diagrams. They're simply a way to capture and refine the stuff on a whiteboard.

3. The data-modeling tools supporting logical and physical models suffered from some of the same needless complexity as the attempts to codegen from UML. And from the ludicrous expense of the tools. Every place I worked had at most one license for those tools.

5. The code-navigation and code-completion features in modern IDEs implement some of the best parts of the UML codegen vision. Tell VS that a class implements a particular interface, and it offers to generate a skeleton of the necessary methods for you. Great. Look at a method declaration, and see at a glance that it's from a superclass. Also great.

6. I hope somebody, maybe the author, collects articles like this for a text to be used in software engineering teaching. Our trade needs some serious mid-career training. The military has the Army War College. We need the Software Wars College, to get a chance to think this stuff through.

7. PlantUML is a pretty good way of embedding UML in wikis and other online docs. "Pretty good" is good enough for most purposes.

This answer to your question is more about scaling out (many machines) than scaling up (big machines).

Many budget hosting providers supporting CMSs like WordPress and Joomla run very large multitenant MySQL or MariaDB instances. These instances often get into performance trouble when one or more of the customer sites on them grow large or get traffic spikes. The CMSs offer elaborate caching strategies (based on redis, memcache/d) to help mitigate this. But of course the multitenant nature of these instances means that individual customers must configure the caching. And the lowest-end hosting providers don't offer redis or memcache/d.

It's possible to monitor various operational parameters (via `SHOW GLOBAL STATUS` and similar SQL statements) to detect problems. It's very hard for customers to mitigate configuration problems (like insufficient buffer pool sizes or too few maximum connections). But customers can change table indexes.

Other hosting providers operate large numbers of small separate MariaDB and MySQL instances, one per customer. Considering that WordPress powers something like 30 - 40% of the sites on the internet, the total number of instances is vast.

WordPress.org, a vast site, uses multiple read replicas.

Version upgrade inertia is a big problem for hosting providers. One provider (whom I will not name) runs a MySQL version that reached end-of-life well over a year ago. New-start MySQL / MariaDB project designs should make provisions for DBMS version updates. Updates are worth applying because the development teams do lots of performance-enhancement work.

Cymru is the Welsh-language name for Wales. I wonder how this cybersecurity outfit picked the name? Anybody know?

This is great. Especially because it's the work of a highly motivated and gifted person who doesn't crank code for a living. I'd say "gifted amateur" except the only thing amateurish about this is that it's a labor of love.