2,163 karma · joined June 1, 2023
Whenever there was a lot of rain up the mountains, my parents would keep watch during the night as it takes as little as 20 minutes from the start of rain to the wall of water reaching our location.
Actually, you could get anywhere in the reachable Universe.
For example, it takes only 29 years to from Earth to Andromeda galaxy assuming constant 1g acceleration for half of the trip and then constant 1g deceleration for the other half.
Black hole does not have a surface. At least not that we know of. Event horizon is a surface, but it is not the surface of the BH in conventional sense. If you were falling into BH nothing special would happen as you crossed event horizon.
And neither does the Sun. Just like Earth's atmosphere, we can only talk about some arbitrary altitudes or pressures, but reality is that the atmosphere of the Sun or Earth does not have any firm beginning or end. And Sun is all atmosphere.
The shape of gravitational field only differs within the body. The shape outside of the perfectly spherical body will be exactly the same regardless of how the mass is distributed (whether it is all on the surface or all in the middle of it).
Or in other words, if you are on the surface of the sun, you will feel exactly the same acceleration as if entire mass of the sun was concentrated in its center.
The only time you feel the difference is if you dip into the sun. As you go deeper and deeper, the pull from all the mass that is further from the center than you are will perfectly nullify each other. As you go deeper and deeper into the sun you will feel less acceleration.
The database I implemented did not allocate any memory and used a constant amount of stack which was important for me to ensure the application can be verified statically.
So the database worked by having two files allocated. The application would append data to one file, then when it was full it would copy live entries to the other and start appending there and so on.
This might sound wasteful but in reality write magnification was very low. There was very little data that needed to be copied, most records were created and then promptly deleted when it was reconciled with the server.
All sorts of data was written to the storage. I started by writing just basic transaction information but then I discovered that I can also log other information (UI state, etc.) to recover state in case of power failure. This was extremely efficient, most UI operations would result in only a single byte written to the flash. This was important as the flash had quite limited durability and was typically a limiting factor for the longevity of the device.
**
Now that I remember, there were other fun tricks I did.
One of them was for the OpenSSL. This super underpowered device took no less than 9 seconds to open SSL connection over GPRS.
That was fine when the device was first designed and we deployed lots of them. Initially, we did not need SSL and we did not need to open any connections to complete the transaction. We only did that later, once a day, to send all of the information and reconcile with the server.
But at some point we had to deploy ability to do online check with the bank and also required to have all connections secured with SSL. 9 seconds for the client to wait on the transaction was definitely not acceptable.
While we could try to keep the connection open, in many cases the device would be deployed in places with poor connectivity and it was just unreasonable expectation.
I saved the company A TON of cash by figuring out I can gut the OpenSSL library to be able to manually save and restore cryptographic state of the connection (symmetric cryptography). I did the same for the system that terminated connections on the server.
The application would connect to the server, skip entire handshake communication (not even a single handshake packet) and would immediately, speculatively switch to the stored symmetric key.
The server kept a database of all most recent cryptographic states with each of the known terminals and would try to match the communication with its own stored cryptographic state. If this worked, it would continue as if nothing happened. If it did not, it would close the connection. The terminal would then restart the connection with the complete handshake from scratch. But it very rarely had to. As it was very successful, we had to add a functionality to force to clear the state every night so that it we knew there is at least one fresh connection every day.
This cut down almost all of the overhead of OpenSSL.
It was credit card terminal application. It was supposed to behave correctly regardless of when in the process of transaction something happened. Something could be application crash, power cycle, etc. Users were frequently impatient with the slower communication methods (we had land line and GPRS modems back then) and would frequently power cycle the terminal if it took a moment too long to do something.
I designed the application in such a way that it always moves transactionally between series of well defined states with no observable states in between. Then I put test points between the states to crash the application at random. Many of these points were put in places in code which would be extremely difficult to test other way (it was extremely unlikely a power cycle would happen naturally at that exact point in time, between those two exact instructions).
The application had capability to crash at literally any point and simply continue operation once power cycled.
(Mind I mean the discussion is misguided, not you)
The problem is that relational model is a one solution to certain problem of when you want to pay the price of enforcing the model of your data. Relational database is when you pay all the cost upfront.
With MongoDB I have other options.
It does not mean they are necessarily better options. But some of them are better in some situations, for example when rapid prototyping. Or when you need to preserve data in different formats as the application evolves.
Personally, if you can, you probably should model your data upfront. But it is good to have other options, sometimes.
I also happen to know Java (almost 20 years of experience with it).
The point of rewriting it to Java wasn't just the Common Lisp. Compiling and injecting code into high throughput, live, mission critical application proved to be too much of a challenge for developers we tried to hire. Even if I rewrote this for Java (which I absolutely had no intention of doing) the problem would still persist. Most Java devs have even worse understanding of the low level operations than Common Lisp.
That's essentially my experience. There is something about developers... they learn a new language but most people never really learn a new way of thinking.
I worked with one guy who tried to learn Common Lisp and even after a year on the project his code was essentially Java written in Lisp.
But this isn't really a problem with Lisp, specifically. I had the same problem with pretty much every programming language. Just recently I had fun debating the usefulness of Kotlin as a programming language. In my experience, for all the features Kotlin has, every single Kotlin program I have ever seen looks like a Java program translated line by line to Kotlin. Which is to say none of the Kotlin features are actually used to solve any important problems like reducing complexity of the application.
> Common Lisp doesn't have too many particularly odd language features;
I would say for most developers I worked with the biggest challenge was always getting the idea of macros. There is technically no reason to use macros. But if you do not use macros you are not really programming Lisp.
The point of macros is the reversal of the programming process. In a regular programming language, you get a bunch of tools and then you learn the tools and then you figure out how to write program using the tools.
In Lisp, you figure out how you want your program to be written, and then make tools that make it possible. It is quite a big shift in thinking that many people have trouble with.
Once I got this, I am now using similar technique in other programming languages. I am looking at my problem and extracting the core complexity and try to figure out what would be the best way to write that complexity down as code. Then I figure out all the machinery to make it happen. It not as elegant as in lisp but it still leads to way better and more readable code at least where it matters.
Testing out technology on important projects is reckless and is a risk a lot of people take but push away any responsibility for.
As a professional, before I suggest to use a technology at a project, at first at the very minimum I spend some time with it to learn the ins and outs. Every technology has cons. Just because you don't know them does not absolve you from responsibility for them.
The reality is that most applications are boringly similar once you define the problem in simple words. There is very rarely a need to use new technology. It is my experience that it is usually better to use technology that is not necessarily cutting edge but one that you know well and that you can easily hire people who know it well.
Because no technology is perfect, but it is much better to know the cons ahead of time and know you will have people who will know the problems and who can find reasonable solutions for.
I am personally sick and tired of people who first advocate for new technology to be added to the project, touting its supposed benefits, not knowing the cons, then don't want to take responsibility once we actually find the dead bodies.
More precisely, this was SBCL/ANSI C application where most of the application was implemented in Common Lisp, some OS / low level stuff was written in ANSI C and same things were written in Lisp to compile to machine code and inserted into "C world".
There would be no Common Lisp virtual machine on the critical, low latency path. Instead, the high level code would be used to configure and construct the low lever path. For example, I would have a bunch of Lisp code to create decision trees, then get them simplified and compiled to machine code, then machine code would be inserted into the path of oncoming market data.
Or Common Lisp code would be used to take a bunch of XML files with descriptions of binary messages in XDP format, but then those macros would be used to generate efficient machine code for parsing and serialising messages. I actually stole this idea wholesale from fantastic book Practical Common Lisp (thank you Peter Seibel!)
SBCL was wonderful to work and tinker with. Love cffi and vops and the macros that bring it all together.
The sad part is that it was impossible to get anybody else working on it and I had to rewrite it in Java (and destroy performance in the process).
Such is the curse of Lisp, unfortunately. And polyglot programming is not really for large corporations. It is hard enough to find people good at one specific programming language, it is almost impossible to find somebody who will be good at both extremely low level (like understand what the CPU does when it gets an instruction) as well as the highest level (complex abstractions with Lisp macros, etc.) for a project where pretty much everything is custom.
Anybody who makes tech decisions based solely on what PR teams say is naive and incompetent at best.
MongoDB is a document database. It is not supposed to be good at relations. Also lacking support with cloud providers and lacking experience with MongoDB is not MongoDB's problem, it is your poor decisionmaking. If you value those things, you should have taken it into account when you were choosing MongoDB in the first place.
Now, I am not a big lover of MongoDB. Some years ago I was forced to use it and I had very low opinion of it as quite immature product. It is still far behind in maturity compared to something like Oracle database or PostreSQL, but in the meantime I learned to appreciate some of the things MongoDB is good at.
I also admit that MongoDB's transactions are a total joke. It should be prominently placed in the documentation that you are using them at your own risk. I don't use MongoDB transactions anymore because there are better ways to architect your application with MongoDB without using transactions.
I like MongoDB for the ease of use when rapidly prototyping things. I like the concept of a no-schema, document database and some of the additional features it provides to deal with the document. I like its reactive java driver which is a breeze to use to construct data pipelines quickly. I like change streams.
In the end, I think it is good to have a selection of tools that are good at doing different things.
It is our responsibility to chose the right tool for the job. If you chose poorly, don't try to fault the tool for it.
The only reason stock buybacks are thought of in negative light is that they seem to be a way for companies to not pay taxes... but the tax law is not companies' fault! It is our fault for the tax law to be this way!
Which is to say "let's just pretend that all of those pesky details do not exist".
To be able to appreciate realities of what Boeing is doing and not just focus on financials. The point is it does not matter how much you know about financials or business management if your product sucks. And there are way more people who know finances and business management than people who can appreciate the kind of engineering that happens in aerospace, so you want a person who knows engineering.
People who engineered bridges during Roman Empire had different tradeoffs to consider than people who were building bridges in 20th century.
Standing for a thousand years is rarely an ultimate goal when engineering a bridge although it is possible that Romans planned for longer timescales than us.
If we decided to build like Romans did, there would likely be very little infrastructure and many structures would simply be impossible to construct.
Exactly. It is only the scale and the viewing angle that makes it seem slow moving.
When any piece in the chain of those forces breaks, the entire structure loses ability to transfer forces and breaks.
This arrangement is what allows us to build these structures in the first place. There is careful calculations of forces and risks and allowance for margin for error and unexpected events. But, unfortunately, in many cases those do not include ramming things with a large container ship...
What I describe is my personal style which has been described as "detective". When things do not work well, I tend to get into the thick of things to get a sense of what is really happening "on the shop floor".
I remember, at the start of my career, my disdain for the execs. I couldn't really understand how you can go this far and yet don't understand the simplest basics of the business we are doing. Now I know that it is mighty hard to have true sense when everything you are being told is carefully filtered and worded, when every person you talk to is completely focused on how they appear in the discussion rather than about solving the problem.
So to fight this I get into a detective mode and I try to appear friendly to people, genuinely interested (which is not hard because I actually am!) and not trying to sound like all knowing and all powerful. And I do defer to engineers a lot, but I also tell them that they need to be able to support decisions with information.
I have been "problem manager" for many large outages. I use the term "problem manager" to remind people that an outage is something you manage just like any other kind of project, except on much shorter time scales.
Everything you learned about project management applies to dealing with outages.
> Sometimes an investigator needs to go silent for a while to chase down a hunch, or collect some data, or research some question. As long as such a silence is negotiated in advance, with a specific time to reconvene, it can serve a crucial purpose. I call this functional dead air.
Hey, if you are the kind of project manager that talks and does not listen to your team... that's a problem.
My ideal stance on those occasions is to present myself as somebody who "wants to be educated about the issue". I think it is more helpful and creates less stress. As I am asking questions I am trying to not seem to be interrogating them but instead emphasise I am a noob on the topic but need to learn quickly.
My ideal is this scene from Margin Call: https://youtu.be/Hhy7JUinlu0?t=67
This usually is actually true, btw.
There is no single way to do it right but as a manager it is your job to maintain good information flow between you and your reports and on an outage, your reports are essentially everybody involved.
Obviously, this would dramatically increase the price of steel but this would now be more realistic price after accounting for how damaging it is to the environment and how costly it is to make that steel carbon neutral.
Or another point of view, the current price of steel is extremely cheap because people who benefit from it do not have to pay for the environmental cost of it.
As to mattress, I prefer a mid-to-hard latex mattress with a cover.
Here the problem is executives who are absolutely shit at understanding what the product of their company is (efficiency AND safety). And absolute shit at understanding that yes, you can extract some additional value in short term by reducing standards, but it will eventually catch up with you and the party will be gone.
If I was investor in Boeing I would be screaming to get these executives fired as they obviously are not acting responsibly with good of my long term investment in mind.
Couple of years ago I have injured my ACL and had to learn to sleep on my back. Now I am much happier sleeper. Now I generally do not move at all during night (I wake up exactly as I have fallen asleep and my sleep tracker tracks way less movement). All of the pains gone.