Welcome everybody, this is Kerry for me, I've never talked to a room like this before,
so big, so thank you all for coming, and let's have some fun.
If the clicker works.
Yes.
All right, so we're going to talk about how to make package managers scream.
First, a little bit about myself, I'm super computing, this admin at Genshin University
here in Belgium.
If you don't know what super computing is, there's a bedroom tomorrow about HPC, HPC,
high-performance computing, come and check it out.
I've been into open source software for quite a while now, yes, I'm getting old, I like
other stuff as well, if you bring me a beer, I'll be happy, and I've been attending for
them for a long time already, and organizing an HPC bedroom for a long time already.
Some people know me from the easy-built project, maybe even the easy project, which is a bit
more recent, but that's not what I'm going to talk about today at all.
Some of you may have seen this, how to make package managers cry talk at Foss Dam, a thousand
years ago.
How many of you have seen it at Foss Dam in the room?
Okay, how many so I don't line?
Couple more.
Everybody else hasn't seen it yet, you should be, you should be watching it, but I guess
for you, this talk will be more fun than for the others.
Let's see, so some people liked it back then, the deaf room was way too small, they put
me in a bigger room this year, thank you very much for that.
It was posted on Hacker News, sort of, like, they were got three uploads, so, okay, it did
get posted on another thread, what's your favorite tech talk, so I must have done something
right.
So it's on YouTube, you can find it on the Foss Dam website as well.
Today we're doing this sequel, I actually submitted this to the package management
and the deaf room which happened this morning, but it got promoted to this, so, all right.
It's sort of more of the same, but also kind of different, so you'll see, something just
trying to have a bit more fun, and as many of you know, and as opening talk this morning
as well, we are living in a different world compared to 2018.
I was sitting here for the two talks before, the audience was very quiet, I hope it's
going to be different for this talk, I want you to shout during the talk as well, speak
your mind, yes, so let's, let's make this fun, all right, so it is going to be a little
bit biased, I work in super computing, I work with scientific software, so there is a bit
of an angle like this, but I hopefully, I will still translate well, how many of you have
their own super computer?
I sort of do, so yeah, the good news is super computers really like Linux, like Windows,
macOS, BSD, just, yeah, no way, yeah, that's true, yeah, not only super computers do
also regular ones, so most of this is actually in the Linux world, but we are at false
names, so that's fine, on a super computer you typically build your software from source,
and that's a lot of fun, I can tell you, so there's definitely an angle to that as well,
the software that we install is often developed by scientists, scientists are very often
not software engineers, so yeah, it does get interesting, and also yeah, super computer
is built for many different people, not one person using it as a laptop, and there's an
angle to that as well, but hopefully this will translate well, let's see, so yeah, package
managers are people too, so they're not only the tools, package managers as a tool, but
there's the people behind this as well, so that's actually what I'm focusing on on this
talk, so I see package managers as the people who are installing software for either themselves,
or somebody else, or at least packaging stuff, so it's easy to install and use, if you
install software for somebody else, I consider you a package manager, so it's a very broad
term, there's sort of first line with a sponder, so they're like the front line people,
if there's a new software release, the package managers get to experience it first, so they
are quite important, I would say, they also don't give up easily, they like solving puzzles,
I consider myself to be a package manager, and I like solving puzzles, if you give me a challenge
I'll spend hours to try and figure it out, what's the different, I don't know, difficult questions
at the end, but the point, I guess, yeah, so package managers have seen a lot, but there's more
of us, there's more of end users, and there's always going to be a minority, and we're also
quite creative, and I'm going to help you with that. So who is this talk for? Well, if you're at
fuzz them, you like computers, you like coding, you like computers, do what you want them to do,
that's very good, you like open your software, again, you're at fuzz them, maybe you don't
like dealing with people, though, you're in it for the computers in the coding, a lot less
so for the people, and especially the people who are trying to use your software,
yeah, maybe you're not a big fan of them, because they'll do weird stuff, right?
They try to install your software and weird environments, they'll ask questions and often annoying
questions, and you will have to come up with the answers, they'll even report problems, or bugs,
what they call bugs, and probably you don't care about them, and they even dare to ask changes
and features and more stuff for your software, so they are very annoying. So why do we want to
make package manager screen then? Well, package managers make it easier for people to install
and use your software, if they can't install a new software, they won't have any questions,
right? So they are, again, the first line of defense. So we don't want that, because if a package
manager is able to do their job really well, I don't only result in more work for us, for the
people actually writing the software, so you want to make package managers give up, right? The best
as we can, and if we can't make them, if we can't make them give up, we want to frustrate them,
we want to slow them down, we want to do whatever we can. So there's a bunch of tips and tricks coming
up that you can use, other any package managers in the room, so anyone installing software for
other people, okay, that's quite a, keep your hand up, that's quite a bunch of people. If you're
sitting next to a package manager, distract them, because we don't want them to know all the tricks,
right? Send them an email, show them a bug, whatever, but distract them. So the goals for this
talk are, well, we want to confuse them, right? We want to frustrate them if they can throw
their computer away, that's good, they can't package manage for, they can't package software for a
while, yeah, confusion, frustration, all of this is what we're really going for. Okay, so topics will
be covering in this talk, it's quite a bunch of them. I'll just list them very quickly without
going into too many details, that this is all prizes, prizes, this is what we are going, but it is coming
up, right? All of this will cover, and we'll have examples as well. All right, so are we ready for
all of this? Okay, okay, I don't know what happened here, right? Right, so first let's start with
the question. So this is a graph coming from Wikipedia about the number of publications and
books and all of this stuff published on LLMs. So you sort of see this increasing,
in 2018, what happened in 2018? That's only made this boom. I haven't, yes, my last thoughts
them talk happened in 2018. So I sort of cost this, maybe, I'm sorry, but they can help us, right?
And yeah, of course I have to mention LLMs, I'll only do it in this slide, and then I'll give up on
them, I promise, but if you use LLMs, you don't need to learn any of the trips or tricks or tools
that I'm be showing you, you just ask LLM to wait for you. If somebody complains hallucinations
by the LLM and you're done, you can even tell package managers, stop packaging software, just
ask LLM to install the software for you. It sounds like a joke, it's not, people are actually
proposing this as a standard, add an installed ND to your repository, tell LLM what to do,
and the LLM will do it for you. So we don't need package managers anymore.
Right? And of course, this is actually a bad idea, because this gives the package managers very
good documentation on how to install your software. So don't do this. Naming things is hard,
right? So naming or project is actually already a first line of defense, if they can't pronounce
the name, if they can't find your package by searching for it. Great, very good. So make
sure it's hard to search for, try to confuse people. If they search for something,
Python is a very good one. It's a snake, right? A good luck finding help on that.
You should also use a project name that implies something that's totally untrue about your project.
That's a very good one. Use funny characters, like there's ASCII characters that you can use,
that are not that common, like a pipe is very good. It's a regular ASCII character, but it's a
nightmare to use it anywhere. Unicode characters are very good, of course, trademark signs.
Maybe you're forced to use them. Unicode stuff, so excellent. Try to trigger typos.
I encourage people to make typos. That's actually coming up. And just be inconsistent as much as you can.
Name your package, name your project, give it one name, name it something else in the documentation,
whatever. If you talk about it, name it something else, and people will just don't know what's
up in there. So here's some examples. Rust, I kind of like Rust. That's a good one.
It's a programming language, but it's also a color. It's a game. A pretty popular game. It's a chemical
process. It's a movie that got a lot of new coverage for very bad reasons, but yeah, so there's already
some room for confusion there. See, in our single letter names? Yeah, amazing to search for. So
getting help for that is easy build is, it's as easy, but it has 250 configuration options. So how
in what sense is it easy? It's not easy at all. This is a difficult one. Ask in this pack
slack for help to install spark and the stack using a spec. It's a valid sentence. It actually makes sense.
See, you can actually use this. Python packages, so there's this weird thing going on on
pipeline that they don't like dashes, and they want to use underscores instead in file names,
all over the place, in file names. So not then things that you import in Python, just the file name,
and he's an underscore. It makes zero sense to me. Good. Excellent. Sorry. M dashes. I'm not sure.
That's unique, so good. Yeah.
These are actual names as well. Open pipes teach up. It's a real name of a project.
Later, it's kind of funny when the camel casing omega has the omega in this omega omega. I don't know,
very good. This is also a nice example of a project. Some of you may know, who knows this?
Hopefully. So it's a bit niche in HPC. It's a dependency for open MPI. Open MPI is something for running
big scale applications on supercomputers. It's short for this, which I can pronounce.
First word is then short for something else. So the whole thing is like process management interface
XSK or reference runtime environment. How do we even pronounce this thing? Is it pretty? Is it pretty?
Are they going for pretty? Maybe. And the other thing is PMIX, PMAX. I don't know. Good. Confusion.
They're very inconsistent in terms of how they use the name. So this is a screenshot from the documentation.
It's formally referred to as, let's say, pretty. And you get to have a directory. It's a lower case.
Okay, not bad. This is the second part of the screenshot. They say, yeah, has two consecutive
arms, which is a bit annoying. So in everything that we do, we'll just use one arm. And that's way better.
All right. So names that you should consider for your own project in the future. Phoenix is a very popular
one. There's a hundred Phoenix's out there, a rise from the ashes. Very sexy.
High-rise, similar, and especially with parallel software, multiple heads. All of this. Really anything
mythology is good. Just pick something from a mythology and you're fine. Some play on snakes, especially
in the Python ecosystem. There's always more snakes that you can use. There's no room for confusion at all.
Everybody knows what each of these are. Maybe. Open something, even if, especially if it's not open.
Use this. And another example is alpha something. If you want to win a Nobel Prize, go for alpha something.
Next to naming the project itself, there's a terminology in your project or in the tools that you use.
So you've stuff that's not standard. Right? To come up with new names for things that are well-established.
Creates are just packages in Rust to me. But they call them crates. Okay.
And then you're on terminology. Use tools that have custom terminology, so make people look up stuff
to really understand what they're dealing with. That makes sense. Over load commonly used terminology.
Like modules is a very good one. You should have modules in your project. Whatever they mean.
There's this Linux kernel modules. There's four-term modules. There's C-make modules. There's Python modules.
There's Ansible modules. There's Infirmable. They all are totally different things. Great.
And also established terminology, like interface, just make sure you mean something slightly different for you than it does for most people.
Yeah, structure of code and Rust of is located. This is one I have a lot of fun with.
So first of all, it's your project. How you want the structure is up to you. Nobody else can tell you what to do.
Right? It's your choice. It doesn't really need to make sense to other people. If it sort of makes sense to you, that's good enough.
If you have source code in the repository, spread it across the whole thing. Deep directories,
as many as you can, makes a lot of sense. Make people hunt for stuff.
Why not? If you have configuration and build tools that you especially develop established ones,
they look for things in standard places. But it doesn't mean you have to put them in the standard places.
You can put them somewhere else. If you have binaries, don't put them in slash bin. Put them somewhere else.
Same for libraries, same for header files. Lib includes, nah, this makes the merchants.
Documentation is also nice. Of course, now you can only have the way with not having documentation.
You'll get so many questions, people will get angry. You'll need to have some documentation.
But it can still be very helpful to make package manager scream. It can be very minimal.
In complete, it can be totally out of date. So not synced up with the source code.
It can be explained, but in a very confusing way. Terminology helps a lot with that.
It can be very long, very boring. Maybe someone you read me filed, maybe someone on the website,
maybe someone actual documentation. We've got nosewant. You can make it hard to search.
A research paper is something we see in scientific software. They only have a paper and that's the documentation.
And they only do an MPDF because it's a bit annoying to search through. Or maybe it's just only the comments in the source code.
That's the real documentation. Sorry.
A word that I should have thought about this. Yeah, thank you. So suggestions are welcome. Yes.
Actually, a word document is not good enough. It should be a word document in a zip file.
Right. You can do levels.
Well, this is getting confusing. Okay.
Pay well. Wait. That's coming up.
Host your project somewhere else. Like not why they expect to find it. I'm not going to call names here, but
be creative. Look for other ways to post your stuff. Package managers like to have an account everywhere.
On every possible platform. If they want to ask a question, make them open an account on
somewhere that they don't have an account yet. Especially if it's slightly different in terms of user interface. So they have to learn stuff.
Right. Self-hosted GitLab is interesting. Especially if you put it behind the wall guard and like you need an email in a certain domain to access the GitLab.
No way to create an account from the outside. Excellent. Don't use Git. Right. Git is everywhere. Everybody knows it. There's many alternatives.
CVS is nice. Look up CVS. On show. Yes.
On share, but you should be giving the talk next year, maybe.
Also scatter stuff. If you have releases, tag some things in the repository, mark some of them as a release.
Have a mirror that mirrors some of the versions, but not everything.
Upload then selections of those from PIPI or have releases from PIPI that don't have a tag in the repository.
Have a website that has a release from five years ago that everybody still uses because they don't know their
other stuff. Yes. Sorry. Sorry, taken.
NFTP server. Yes. Back to the 90s. Yes. That's a very good option.
Yeah. Well, questions at the end because I have many slides. You can include
TARBALS, like zipped TARBALS, zipped files in a repository, in a GitHub repository. It's allowed.
Right. And people do this. Levels, build levels. And you can split your project across many
different repositories as well. Check out Rockham. Very good. Also name, excellent.
You can also package things yourself. So beat them in their own game.
If you do it first, then maybe you'll make it easy for them. Right. If you have installation instructions,
only tell them only let them specify how to do a system-wide installation on a very specific
distribution, like a bunch like a bunch, just an example. Why? Well, some people will think that
you want to is required for your software and they'll figure out a way to install it. This has happened.
We've had cases like this in support tickets, in super computing center. I tried to run
pseudo-upget or apt install, for some example, and it didn't work. And the ticket actually said,
and I entered my password and still didn't work, and I'm sure it's correct.
Okay. And they were doing us on a rail-based distro, which doesn't even have apt. So,
you can install apt. Yeah. Yeah. You can only provide the Docker file as installation instructions.
That's good enough, right? It should help anyone. Why not? You can release your software
as a Jupyter notebook. So the code and the notebook, that's it. This happens. There's a very good
talk on, I don't like notebooks. He has a very complete example of that, where this is actually
tough. As releasing a snap, I'm not familiar enough with snaps, but I guess so, if you're asking
in the question, I guess. You can create your own package manager as well, right? If your thing
is too complex, create your own one. If you're interested in the rock, there's a talk about it tomorrow
and the HPC there. Dependencies, you all knew this was coming, right? The famous XKCD.
There's this guy at the bottom. No, you don't want to be at the bottom. You want to be at the top.
Right? Depend on as much stuff as you can. More dependencies is always better.
Also choose them well, right? Yeah. Usually have many options. The libraries that implement
similar stuff, use the ones that are causing most trouble or most likely to cost trouble.
Obscure dependencies that nobody else is using, those are the ones you want. Right? If there's
new stuff coming up, follow hacker news and jump on stuff as soon as you can, because it will
be new to the package manager as well. You don't actually need to use all the dependencies you
declare. Right? I mean, if the be a bit reasonable, keep yourself sane. Just make your
configuration to like see make it required. Error out and then never use it. And include statements
in your code like C++ and then you don't use the functionality at all, but they need to include files,
so they'll need to install the dependency. If somebody complains, just that you're planning ahead
for the future and you will, of course, actually use those dependencies. It is coming.
So can you win any prizes with applying some of these tricks? Does anyone know the answer?
The answer is yes. Yes, you can. If you look at alpha fold, so alpha fold is, I think everybody
knows it from deep mind. Check the repository. It's a tool with proteins, la la. It's pretty well
now. This is a screenshot from the read me. Step one and stole Docker. Step two and
stole the Nvidia container toolkit, which you view support. Well, step two. One, I guess,
1.1, 1.2 is an, make sure it's set up as an on-road user. Right? And then step two is a good
clone and CD. Like compared to the first step is like this is the opposite of start with the
now and finish the owl. It's actually the other way around. The hard stuff first and then CD.
This is a more of the installation instructions, build a Docker image, right? And there's an error there.
If you see the error link to the comment issue, or very easy, you put into 18. They're using
you've been to 18. So can you in the prize with this? Yes. This one, the Nobel prize is
essentially. Yeah, it's funny, I know. Hidden tricks in your project in your code. Because again,
I mean, you want to keep yourself sane, right? If you apply all of this, you just,
you may start screaming yourself and you don't want that to happen. You can add features to your
software configuration options. Just don't document them, right? Keep them to yourself.
The very easy way of doing that is using environment variables. You set an environment
variable that's sort of hidden, right? And then if it is set, you're sort of to react to it and
does something sensible. Right? They should be hard to find. If the package manages to discover them,
you're screwed. Like don't use the project name as the pre-t fix for the environment
variable. You use something else, otherwise it's too easy to find. And the value that is used for
that environment variable should be something very specific, like not one or own, something else.
So a small example in Python, I hope most of you know Python, right? So you just grab the environment
variable. And if it is set to something, you don't run a test. Pad example, right? It's easy to find.
It's right there. Any decent package manager will find it. Just make it a bit more involved.
Right? So use it. Use a different prefix. Make sure it's not like a single string.
Definitely make sure it's not uppercase, but uppercase it on the fly. And then make sure you have
a magic value that has to be set, not just one, but something else.
Built tools, you all know this is coming as well. So aim for maximum damage.
Can never go wrong with CMake.
See, make all fuses. Everybody, there's many talks, many blog posts that explain you why CMake is
total to crap. It's all over Hacker News as well. Like I would give up my first born if I never
have to, you see, make again. Many people are not very happy with CMake. There's more about
built tools, you can say, you can combine multiple ones. You don't need to stick to just CMake.
Like mix it up, use other ones as well. You can, you can call CMake and make from a set of
dot pi. It's Python code, you can do whatever you want. We see this all the time in a while.
That happens. Sure. Three? Yeah, sure. Cargo just levels. Again, combine stuff.
Add some answer, but why not? Yeah. You can have a script called configured dot pi right at
in Pearl. Nothing is stopping you from doing that. If you have a Python project, make sure you
have all these files in there. And you can have good reasons to have all of them. Several of them
allow you to declare dependencies, like requirement, text, pi project, environment, be
homeless, more for Konda. But you can declare dependencies in all of them. Make sure it's inconsistent.
Right? Don't do the same thing in the different files. It doesn't make sense. Sorry. It doesn't have
this for Python. It's very easy to do. I guess for other things you can do this as well.
It doesn't have to be only in Python. But you're right. Maybe you add them and it doesn't have any
Python code. That's actually good as well. Also, build tools have their own dependencies, right?
Pick a build tool that has like 10 dependencies just to get the build tool to work. Because again,
levels make them sweat. And if you're not just about choosing the build, it's also how you use them.
You can see make as a runtime dependency for your software. Why not? I mean it has functionality.
If there's a function there that you find that does something useful, make it a runtime dependency.
There was a comment there. Forking is coming up. Yeah, you're too fast. Forking is coming.
If see make is not bad enough. Try basil, right? You can get stickers at fuzz them on basil.
Basil, basil, I don't know. More build tools. Sure, why not? If there's documentation on the build tools,
don't read it. Or if there is documentation only use like previous versions.
If there's best practices, don't use them. But just copy stuff from random repositories that you
find. Especially stuff that hasn't been touched 10 years for 10 years. That's the stuff you want.
There's like a classic remake and a modern remake. Don't let me the difference. But I know there's
a difference. Go for the classic stuff. It's more stable. Yes, the classic stuff is more stable. Of course.
But do make sure that you require the very latest teammate version. There's a CMake 4.
Stuff is broken in it. Use that. And if you're lucky if they do a new CMake release,
it will have a regression. You will hit that regression. Perfect. There's actually very useful
website. New releases.io. You can give them your email address. You register to specific projects.
You can get an email as soon as there's a new release. That's when you want to adopt it. They want.
You can use typos and file names and commands as well in your documentation. Just make things look a bit weird.
Like this. Right? So this is... The NAIC-FC-Make lists and type it or take the output,
pushing into pipe project.com. I don't know what this means. Now, some day, a package amount
you will say they must have a good reason for doing it like this. They're going to spend their
whole weekend on a trying to figure it out. Yeah, binary. One of these could be a binary,
sure. Why not? So they have no idea what's going on. Sorry, you can only stuff like installs
on a Tuesday? That's brilliant. That's a bit obvious, right? Just make it only on full moon or
something. Yeah. Software testing. Sorry? Depending on your... Wait, that's also coming.
Testing is important. If package managers install your software, they won't have to have some way
of testing it. Very often they have no idea what the software does. Use this to your benefit. Make it
difficult. Aim for a test with that just takes forever to run, because they'll get up. They'll
machine will burn down. I don't know. Do you know what I think? Yeah, I'd like to make them guess.
Yeah, how long it will take. Very good. Flake it tests are good, right? The package manager
thinks that all the tests are important. They all have to pass. You know which ones are flaky,
which ones you can ignore. Fine. Again, tests can have dependencies, right? You have testing tools.
That may have dependencies themselves. You can build up the stack even more. So just make sure they
have a lot of work to do before they can even run your tests, let alone run into the flaky ones.
My torch is a very good example of this. It has a massive test to me. If you run the full thing,
it's 250,000 tests. Well, over it. If you run it on a single machine, it takes easily 36 hours.
If your machine is a bit too old, two full days is not an exception. They change it every release.
Like, they throw stuff around, rename, restructured things. So if you had tricks, environment
variables that they do have, they rename them across releases, all these things. Here's an example.
I work on easy build. This is for the relatively recent version of PyTorch. It spits out a result.
550 to test failures out of 261,000 something. So 99.98% of test is passing. Is that good enough?
Are the tests that are failing important? How should I know?
And a real package manager will always try to go for the 100%. So that's a very tempting to make
sure the full thing passes. Okay. Put in a test that always fails on a full moon.
Flake, you're in control over the test. You can make them flaky in an interesting ways.
All right. I like the heckling. It's good. Excellent. Keep it going.
Let's challenge you a bit as well. Let's do a live poll, right?
I'll count to three. This is important. Wait for the three.
Right? And then scream, you think is the correct answer. According to you, one answer.
Each. Here comes the question. Don't scream yet.
There's a countdown coming. Wait for the countdown. Which programming language is most likely
to make package manager scream? Again, think about it first. No screaming yet.
Here's the countdown. One, two, three.
Ooh, no. It's C++. If you don't know it's C++, I don't know where to begin with this.
The standard library is okay. It's a standard library. If you have, if you compile C++ program,
it really, any compiler, the error messages are, this has been my life for 20 years.
Trying to make sense. Again, Ella Lems. Yeah. Templates in C++. If you don't know what they are,
look into them. You want to use them. You want to do meta programming in C++.
Meta programming is when your stuff is building. It's actually running your code as well.
So you can do a rate ratio while the thing is compiling. Why not? Yeah, it's perfect.
Linus hates it. The FBI hates it. This is official. The US has done guidelines on don't
use C++ for memory safety. So you want to use it, right? And the name plus plus searching for it.
Yes. There's an excellent talk on this. The worst programming language of all time. It's a two-hour
rant by a guy. And he's hitting exact point after point after point. It's all correct without
repeating himself too much. Two hours in a row. You can not argue that C++ is not the correct answer.
There are others though. Python is nice. All the installation tools, set of tools,
combine them, especially in supercomputers, combine them as amazing. It fills up everybody's
home directory, everybody likes it. Python 4 may be coming soon, right? So there's this free
threading thing, no more gel. That would be a good reason to release a Python 4. How many of you are
all enough to remember the Python 2, 2, Python 3 situation? Most of them. If Python 4 is coming,
it's a bit weird. I think there's some interesting concepts in there. Poor wing of them, okay?
Yeah. Lots of common custom terminology. No way too early. Monads are coming, sort of.
Fortran is not dead. Not at all. It has new standards. It's been there since the 50s.
It's number 12 and this Tiobi index of most popular programming languages. Everybody's still using it.
In scientific programming, it's everywhere, right? So you use it. Learn it. Make people suffer.
C sharp. C++ is enough. You can use C sharp. Java script is, I'm not even gonna, it's a crazy language
and then there's NPM on top. It's amazing. Or there's many other options. There's OCamo.
There's Haskell if you want to use Monads. I guess you can do another language as well. There's
prologue. How many of you have tried to use prologue? Okay. Put things in make sense. There's a
couple. Okay. Many other examples. Bash is a good one. Bash can get very weird, very quickly.
And there's a new prologue language every day. So again, make sure you pick up on them. Use them.
Make sure they are new to the package management as well. Right. You're all language. Yeah. It could be the new one.
Sure. If you're doing software, prologue language that has to be compiled, first. Very good.
Another tool to your toolbox that can be used to mess things up. The compiles makes you
plus plus even worse than it already is. Compiles are massive. They're huge. They're complex.
They're impossible to get into, to study them, to fix bugs that you may run into. If the compiler
crashes, they're just lost. Like forget it. You'll never figure it out. And if you're doing any
series work, especially in computing, you want to compile your stuff down to a binary so that
can be fast. So you really need to use compiles. Again, the error messages I know, it wasn't the last
slide as well. But screen filling error messages that you don't even know what all the words mean.
It's amazing. Defaults of compiles change a lot. Like GCC has good documentation. Well,
it has documentation. That tells you what has changed about the impact maybe. You get like disappearing
include suddenly you need to add the include before it was automatic. Now it's not anymore. I'm sure
they have good reasons to do it. Compiles have dependencies too. Like this XKCDC, this could be
a compiler on top. It depends on all the stuff already. They even depend on each other. If you
need to build a compiler, you need another compiler to be, how do you start this? Yeah. And there's
a lot of diversity. There's GCC, there's LVM, Intel, AMD, Nvidia, I can go on. Explore the
alternatives. Try to use compiles that the package menu is not familiar with. You don't need
to stick to GCC. It's not because everybody else does that you need to. And even better,
try to make sure that GCC doesn't work. You can do stuff in your code if you know about a good
bug in GCC that's been long standing and you can trigger your code. Use it. Yeah. Compiler
extensions, compiling trends exist as well. Yeah, there's all stuff you can make sure your code
only works with one one. TensorFlow, the people who have seen my previous talk, this has been
the pain of my existence for years. It's implemented in C++, number one. They have pre-built
binaries on PIPI, but they're generic. So generic means they're slow, essentially. They work anywhere,
but you don't really want to use them. You want to build them from source. This is real next thing.
Don't look at them. It still uses base, less configuration too. Good. Everybody loves base.
They stopped recommending GCC. They said, you need clang now to build TensorFlow. If you report
problems to the MHCC, I think a recent version of TensorFlow even literally makes GCC crash,
did you say, sorry, we'll recommend clang. So you're on your own. There's a magic environment
variables everywhere when you install this thing. Guess what they start with, not with TensorFlow.
They start with TF because TensorFlow would be too long. And bonus, if you know about one,
like TF need clang, you can't find an indentmentation, so it doesn't exist.
And this comment here, this is from even before my last talk, it's part of easy
build that shows how to build TensorFlow. And it has a command where part of the command is slash,
slash, TensorFlow something something. And they're going to comment it like the double slash must be a
type of, right? No, it's not, that's how base it works, you know?
Dr. reversioning, yeah, don't waste this opportunity, this is a very good one. You can confuse people
quite a lot with software versions. You can suggest that you're using semantic versioning, but then
don't, right? Ever since Python three years or least, almost every Python three version
has breaking changes in them. So they're not using semantic version, they're not telling you
that using semantic versioning, but it sort of looks like they do, same thing for Lua.
If you want to, if you want to have creative, you can start with calendar version. Like you don't
know you're working on it, don't know when it's going to be good enough. If it's good enough,
release one dot zero, then change your mind. Next, please make it zero dot x, keep going like this,
let the package manage to figure out what the latest version is. They will have no clue.
Again, a real example is the F5, some people from the scientific community may notice,
stable releases of HDF5 have an even minor number. So one dot eight, one dot ten.
Development releases, like you mean trunk, no, no releases, but development, so don't use them,
have an alt minor number. But the major number is one, which is odd.
Okay. Now, I had this idea for a while to put this in the slides, but they have HDF5,
2 dot zero and adopted semantic versioning. So no more even odd. Why did they do that?
Is it because zero is not odd or even or, or they like on short and said that we do 2 dot
2 was the first release? Yeah, you're always getting the best. You can read up on this on this
URL. Look at the URL. It's not because it should be hard to find, I guess.
Forking somebody mentioned forking. Forking encouraged people to forke your software,
tell them not to rename the software. Use the same name just with a different versioning scheme.
Open phone does this. It's scientific simulation software. There's like three different version
of open phone. The only way you can tell them apart is based on the version number. One uses like
year versioning, the other just one X2 X, and the other one and yet something else. But the only
there are only open phone. Open from dot com, open from dot org are two entirely different versions.
All right, I'm slowly getting to the end here, while on time. There's a couple of things we didn't
get to cover. I talked a little bit about Python, but there's I could talk the whole day about
Python. Don't look up UV. You don't want containers or you can build your own messy world
and the container and you give it to someone else. You see, trust me, this is fine. I won't tell you
how it's built, but it's fine. Make it all, how do you make your software, can you make your software
depend on Kubernetes? Can oh yes, then you should. Yes, then you should. Make sure while the installation
is going of your software, while the build is going, download stuff from the web. You want to make
sure the system is online, the internet is there forever, nothing ever disappears,
same thing in test, make tests, download one megabyte data files because you don't want them in
your source code. That would be insane. Gargo is very good at this. So, private server. Yeah,
I need a password. Yeah. Yeah. Again, build tools, test tools. Yes. If you produce error messages
during installation, you're in control, right? You can make them very confusing, very misleading,
print out errors that are religious warnings, print out warnings that are actually errors.
The pip is very good at this. If you do pip that's called something else, it gives you like a wall of
text and the actual error is like the tent line or something and then a whole bunch of junk below that.
And one thing I didn't talk about, then which is important in scientific computing and I guess
more general as well. There's upcoming CPU families, arm is really here everywhere, people have
laptops with arm, risk five is coming soon, so all of this is going to get a lot more reverse than
it already is very soon. All right, and there's probably stuff I missed, right? So if you know about
other stuff, shout as long as there's time or come and talk to me, I'll be here all weekend,
come have a beer. Thanks a lot.
If there are now or any questions, I may be in trouble. Do we have any questions or heckles,
suggestions? Raise your hand if you have any questions. My nickname is, that's a secret.
I won't tell you how to pronounce it. If you want to learn how I got the nickname,
if I understand it correctly, uh, lots of researchers from the physics department in New
Amterpa are calculating again now. What is the worst thing you encounter with them?
Sorry, researchers in the physics department of the anthrop university are now mostly calculating
again. Now that Amterpa's made your money. What is the worst problem you had with them?
What is the worst problem you had with them? The worst problem with the people from Antwerp.
I don't tell people apart. I barely know names when I answer questions, so
No, there's no, it's not like people from Antwerp were smarter or worse than in others. No.
We got in build systems. You don't need to stick to see make a base. You can
wide your own build system, just for your own project. Yes. Looking at your own form.
Open form, yeah. I didn't mention that, but open form does this. Open form has W make,
sounds familiar, something totally different. It always has exit code zero, whatever happens.
If the build fails, all good.
Here, I've got a question. Why didn't you mention about moving tags in the repo?
Moving targets? Yeah, yeah, yeah, yeah. I didn't mention that, but it's not because you
tag something that it has to stay there forever. This is something I mentioned in my last talk,
I guess I didn't mention it here. But yeah, if you tag something today, change it tomorrow.
Why not? I mean, just move the tag. We actually called PyTorch doing this at some point.
Yeah, rewrite history. You forgot about keeping track of versioning in Excel.
In the spreadsheets, in the zip file. Yeah. Yeah.
In a word document, yeah. Levels. How many of these are applicable to automating your updates
with dependable? Oh, sorry. Yeah, how many are these? I'm not sure if dependable is going to
like what you're doing here. And if it likes it, what I'm doing here? Yeah. I don't know. Does it?
Well, a dependable is running. This is my level of open source. Let the dependable do it
with sting and make the noise. It's just ignore it. Everybody does. No. You get the emails,
you get the alerts, and then you say, yeah, maybe tomorrow.
Hello. Oh, you should do daily releases. Are your release pages?
Hello. Are there? Yeah. Okay. You should have daily releases. So you could make your release pages
as long as possible. You don't know. Oh, yeah. Yeah, release like every commit. Yeah.
And you don't need to, the tag could be the commit idea itself. Because it doesn't sort, right?
I recommend to not use a version control system, but just release tablets and only the latest one.
For example, live media removes stuff that has been released before, because it has had bugs, right?
So why would you ever, and also release on multiple platforms with different content in the
tablets? Oh, yeah. And please make sure that the content of the tablet doesn't match the tag.
Oh, yeah. Yeah. Pipi, tagging. Yeah.
Only published patch files open phone. No, not open phone. Warf does this weather modeling software.
They release something, and then they have not even patch files. They have a documentation
page that says for Warf version 3. This is what you want to change. Go to line in this file.
Check the previous talk. You think you have good ideas, but there are three levels deeper than you are.
But we're not also work to ship your dependency source code in your repository.
Yes. Yeah, and change it just enough. Yes, that you cannot use the system library.
Even if they think they know what they're dealing with, no, they're not because you can't.
Hey, you meant us this. Yeah, many people, many tools do this. It's way easier than, yeah, more.
Something I have so wants in real life. In the link in the documentation, make and then link
like randomly something else. Be creative. Be creative. It's great. Record them, yeah. Yeah.
The fundamental question, why to use English? Why to use it?
That that's falls into the confusing category for documentation. Use the Norwegian.
In the way it's whatever.
Maybe one more. I have a question. I didn't. You mentioned Homebo. I mean,
Rust has its own terminology, but only for people who just Rust. Homebo has its own terminology for
every package. Homebo and homebo. No, so Mike Mike made me still be in the room. He's bigger than me. I'm not going to.
I mean, Blue has it's all related to beer, so it should be to your tests.
I don't know if Mike is in the room, so I'm not going to answer that one.
Looking at the time, I must say we should end here. It was a great fun. Thank you very much.
Maybe give a warm applause.