fix: ordered the notes and removed the datasets dir

20 files changed, 110 insertions, 21 deletions

diff --git a/notes/meetin2.txt b/notes/03_06_2026.txt
index 6ed2515..6ed2515 100644
--- a/notes/meetin2.txt
+++ b/notes/03_06_2026.txt
diff --git a/notes/2026-06-10-jd.txt b/notes/10_06_2026.txt
index f058da1..f058da1 100644
--- a/notes/2026-06-10-jd.txt
+++ b/notes/10_06_2026.txt
diff --git a/notes/auto-scaling.txt b/notes/11_05_2026.txt
index a6b009f..6a74ff9 100644
--- a/notes/auto-scaling.txt
+++ b/notes/11_05_2026.txt
@@ -41,3 +41,23 @@ Why is a specific datacenter digital twin different from what there already is.
 
 Versen Thesis Awards they are promoted at ICTO today and tomorrow. 
 
+Create a model in draw.io
+Look at OpenTelemetry (read up - is this a lot of work?)
+https://github.com/atlarge-research/opendc/tree/radice-paper
+Make sure you the fields you specify in the schema itself are automatically exported.
+Measure Kafka latency of exporting. 
+Also ensure whether the user wants to export to database or not.
+Add multiple export functions.
+Make sure specify the config files in the command line.
+The prediction should be about auto-scaling.
+BUT -> there is no auto-scaling.
+Do auto-scaling.
+Idle power takes a lot of energy. 
+Predicting when to turn nodes on and off would be nice.
+Datacenters are heavily underutilized.
+Predict when to turn the hosts on and when to turn them off.
+Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. 
+With auto-scaling you can do it a bit smarter or not.
+Do auto-scaling in OpenDC.
+Rescheduling.
+
diff --git a/notes/notes.txt b/notes/12_05_2026.txt
index d5394cf..d5394cf 100644
--- a/notes/notes.txt
+++ b/notes/12_05_2026.txt
diff --git a/notes/1.txt b/notes/13_05_2026.txt
index 4a11803..4a11803 100644
--- a/notes/1.txt
+++ b/notes/13_05_2026.txt
diff --git a/notes/meeting.txt b/notes/16_06_2026.txt
index 788ca85..788ca85 100644
--- a/notes/meeting.txt
+++ b/notes/16_06_2026.txt
diff --git a/notes/17-06-2026-jd.txt b/notes/17_06_2026.txt
index dc2c9f0..1f2423d 100644
--- a/notes/17-06-2026-jd.txt
+++ b/notes/17_06_2026.txt
@@ -22,7 +22,11 @@ Have a bit of an introduction on the very first slide.
 How does this work affect society at large?
 
 4) After comes the problem statement OR the research question.
-You can KEEP the problem statement.
+You can KEEP the problem statement.We used
+AIP, DBLP, and Google Scholar as the main
+digital libraries for querying the literature
+sources, amongst which Google Scholar re-
+ferred to
 You can also show the contributions.
 
 5) Design to present --> USE Animations to make things appear one by one.
diff --git a/notes/meeting_19_06_2026.txt b/notes/19_06_2026.txt
index cdd1838..cdd1838 100644
--- a/notes/meeting_19_06_2026.txt
+++ b/notes/19_06_2026.txt
diff --git a/notes/20260513_140457.png b/notes/20260513_140457.png
deleted file mode 100644
index 15f29c1..0000000
--- a/notes/20260513_140457.png
+++ /dev/null
diff --git a/notes/23_06_2026.txt b/notes/23_06_2026.txt
new file mode 100644
index 0000000..b5b8075
--- /dev/null
+++ b/notes/23_06_2026.txt
@@ -0,0 +1,19 @@
+Try to make the demo after slide 7 so that it shows Kafka and Postgres receive data from the real datacenter.
+Just to show things are connected.
+Consider showing the experiment with alarms live.
+Figure 1.5 is fine.
+Change the caption to figure 1.5, it cannot be just another text-box i.e., make it _less_ informative overall.
+Caption 1.5 -> visualisation of the digital twin.
+Currently the caption 1.5 is NOT the description of the figure.
+TODO("Change caption 1.5. Captions should be shorter, figure descriptions should be in captions, at most one line description if you _really_ want to have it in the caption.")
+
+Make the "Solution - use a 2nd simulator" green instead.
+Change the "how did you solve the problem" into green.
+Keep the upper cloud ("the problem") red.
+
+Align figure 1.5 better --> do not make the lower part of the figure moved to the left.
+Change the figure 1.5 so that it is aligned vertically.
+
+In your figure it is not clear that what you see on the top is the problem.
+The second thing is too similar to the first thing in the figure.
+If you align that perfectly (the first thing and the second thing), align everything, AND you add some clear some arrow, it becomes more clear that "this is an implementation of that".
diff --git a/notes/24_06_2026.txt b/notes/24_06_2026.txt
new file mode 100644
index 0000000..8bede01
--- /dev/null
+++ b/notes/24_06_2026.txt
@@ -0,0 +1,66 @@
+==__==
+Typically atLarge is a bit more lenient when it comes to deadlines.
+You can submit your thesis until 15 of July by the faculty, but by atLarge you can submit it even later.
+Make sure you tell your supervisor when you plan to hand in your thesis.
+
+For the findings and the experiment section really try to follow the format that we have tried to teach you:
+1) Show what the main findings are
+2) Show the main setup
+3) Have multiple plots or tables to show your finding
+
+Recipe to explain experiments:
+How to evaluate something?
+Real world setting, simulation, mathematical analysis etc.
+Argue that --> "We do simulation based experiments".
+For experimental approach -- checklist:
+1) Workload --> I should explain what I run on my system and why that makes sense.
+You have a simulator run something, or you will inject failures, or you will expose the system to something.
+Is it realistic to expose the system to this workload?
+Does it make sense?
+
+2) Environment --> For a simulator: on what machine do you run the simulator, does it make sense to run this kind of experiment on the machine.
+
+3) (System-under-test) -> How did you configure OpenDC? What settings did you configured to run it? How did you configure redis?
+How did you configure the Kafka filters? Why does these settings make sense?
+
+4) Metrics --> why are you measuring these metrics? Why does this make sense?
+Why are the metrics representative.
+
+If the experiment setup is standard --> you can skip over it.
+You can say that you did a look through the literature about the kinds of use-cases your work can be beneficial for.
+One of the use-cases is an experiment that this related work, (DyTwin) did.
+Through my work I designed and Implemented this to be something that you can experiment with easily instead, not one-off.
+DyTwin was a one-off system. My system allows experimentation like this much more convenient, and NOT one-off.
+DyTwin was one-off system, now using our system can do this much more easily and not one-off.
+We IMPROVE on the work of DyTwin.
+
+We replicate their experiment, we get practically the same results, that validates THEIR work and YOUR OWN work.COMPARE on the same slide THEIR results, and OUR results.
+
+A lot of questions will be about the soundness of your approach.
+There will NOT be a lot of questions about the technical details.
+The more senior people in the room will ask more questions about the methodological approach.
+You DESIGN-ed a system: "what method did you follow for system design?"
+"Why did you choose that method? How did you follow it?"
+"How do you argue that you answers for research questions are good?"
+"Are your research questions good? Why are they good? Why do they align with the rest of the thesis?"
+"Argue why your research questions are challenging, why are they scientific?"
+
+Approach, research questions, methodology, the analysis of experiments.
+Frequent experiment analysis questions: "Why just the mean?" "Is there performance variability?" "Do you always get the same results?" "What can we learn if we look at the distribution?" "How many times did you repeat your experiments?" "What is the standard deviation?"
+
+SHOW IN YOUR ANSWERS YOU HAVE A JUSTIFICATION FOR THESE QUESTIONS.
+Explain that you have though about things.
+
+If you do not know the answer say: "Let me speculate..."
+Indicate honestly that you do not know, and then try to answer.
+
+As a presenter: be there just that day.
+Ask questions during other presentations.
+Support your team.
+Be there for the entire day or your slot perhaps.
+The rest of the day is appreciated, the entire slot is mandatory.
+Agree with the supervisor whether you passed or failed the presentation.
+It never happened that we let someone present and THEN fail.
+Usually they tell them that they have to do on more or two more things.
+Once you have some answer to your research questions, it is heavily unlikely you will fail.
+
diff --git a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf b/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf
deleted file mode 100644
index 4e51e3d..0000000
--- a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf
+++ /dev/null
diff --git a/notes/dante.txt b/notes/dante.txt
deleted file mode 100644
index 6c55eb3..0000000
--- a/notes/dante.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Create a model in draw.io
-Look at OpenTelemetry (read up - is this a lot of work?)
-https://github.com/atlarge-research/opendc/tree/radice-paper
-Make sure you the fields you specify in the schema itself are automatically exported.
-Measure Kafka latency of exporting. 
-Also ensure whether the user wants to export to database or not.
-Add multiple export functions.
-Make sure specify the config files in the command line.
-The prediction should be about auto-scaling.
-BUT -> there is no auto-scaling.
-Do auto-scaling.
-Idle power takes a lot of energy. 
-Predicting when to turn nodes on and off would be nice.
-Datacenters are heavily underutilized.
-Predict when to turn the hosts on and when to turn them off.
-Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. 
-With auto-scaling you can do it a bit smarter or not.
-Do auto-scaling in OpenDC.
-Rescheduling.
-
diff --git a/notes/image (2).png b/notes/image (2).png
deleted file mode 100644
index be41833..0000000
--- a/notes/image (2).png
+++ /dev/null
diff --git a/notes/20260513_140254.png b/notes/screenshots/common_pitfalls.png
index 3ebc53a..3ebc53a 100644
--- a/notes/20260513_140254.png
+++ b/notes/screenshots/common_pitfalls.png
diff --git a/notes/image (1).png b/notes/screenshots/good_figure_from_dante.png
index be41833..be41833 100644
--- a/notes/image (1).png
+++ b/notes/screenshots/good_figure_from_dante.png
diff --git a/notes/image.png b/notes/screenshots/good_figure_from_dante_2.png
index 09c7043..09c7043 100644
--- a/notes/image.png
+++ b/notes/screenshots/good_figure_from_dante_2.png
diff --git a/notes/20260513_133444.png b/notes/screenshots/introduction_timeline.png
index ed2124d..ed2124d 100644
--- a/notes/20260513_133444.png
+++ b/notes/screenshots/introduction_timeline.png
diff --git a/notes/20260513_135756.png b/notes/screenshots/map_of_thesis.png
index a0729d8..a0729d8 100644
--- a/notes/20260513_135756.png
+++ b/notes/screenshots/map_of_thesis.png
diff --git a/notes/vu_thesis_template_advice.pdf b/notes/vu_thesis_template_advice.pdf
deleted file mode 100644
index 8eb63fe..0000000
--- a/notes/vu_thesis_template_advice.pdf
+++ /dev/null