2024-02-06, 12:30–12:35, D.Aud
When software is installed on your OS, plenty of assumptions are made. That you have an up-to-date kernel that software X is already installed that library Y exists somewhere on your system, and so on. But, of course, these assumptions don't translate well between systems, even of the same kind. So, how can we deal with this?
Software engineers don't regularly think about their dependencies, and how deep they can run. They'll install a library onto their system because otherwise their program won't run, and will forget about that library's installation soon after. However, once they try to deploy it to another machine, that problem all of a sudden re-emerges.
It's often the task of the person in charge of that "remote" machine, to fix it. Well, what if that remote machine isn't of the same kind as that of the developer. Even worse, what if it is, and it still fails in some peculiar way.
Bryan will briefly touch on this problem space, and provide some possible solutions to it.
Bryan's been interested in computing for as long as he can remember. Even studying electronic engineering, just to understand how a computer could add 2 numbers together on a transistor level.
Recently, he's been interested in the smaller details of operating systems. How they work, why they look they way they do, and why LISP machines never took off.
Please don't hesitate to approach him about anything tech, or music, related. But, be warned, he has a tendency to just keep on talking once he gets going.