Merge branch 'dev'

Removed julegave to erlend

_data/ntnu-courses.yml

@@ -11,14 +11,6 @@
       course: tfe4130
       desc: Bølgeforplantning, våren 2021.
       updated: 2021-01-12
-    -
-      course: ttk4145
-      desc: Sanntidsprogrammering, våren 2021.
-      updated: 2021-05-04
-    -
-      course: tiø4252
-      desc: Teknologiledelse, våren 2021.
-      updated: 2021-05-04
 
 # Høsten 2020
 -

_includes/utils/scripts.html

@@ -2,7 +2,6 @@
 <script src="{{ "/assets/js/jquery-3.5.1.min.js" | relative_url }}"></script>
 <script src="{{ "/assets/js/bootstrap.bundle.min.js" | relative_url }}"></script>
 <script src="{{ "/assets/js/bootstrap-toc.min.js" | relative_url }}"></script>
-
 <!--Anchors-->
 <script src="{{ "/assets/js/anchor.min.js" | relative_url }}"></script>
 <script>
@@ -11,4 +10,4 @@
   icon: '#',
   };
   anchors.add('h1, h2, h3, h4, h5').remove('.no-anchor');
-</script>
+</script>

_layouts/layouts/lecture.html

@@ -1,20 +0,0 @@
----
-layout: default
----
-<div class="jumbotron">
-	<div class="container">
-		<h1 class="no-anchor" data-toc-skip>{{ page.title }}</h1>
-		<p>{{ page.description }}</p>
-		<small>Forelesningsdato {{ page.date | date: "%d.%m.%Y" }}</small>
-	</div>
-</div>
-<div class="container" id="main">
-	<div class="row row-offcanvas row-offcanvas-right">
-		<div class="col-xs-12 col-sm-12 col-md-9">
-			{{ content }}
-		</div>
-		<div class="col-md-3 d-none d-md-block" id="sidebar">
-			<nav id="toc" data-toggle="toc" class="sticky-top" style="z-index:1"></nav>
-		</div>
-	</div>
-</div>

about.md

@@ -4,8 +4,4 @@ title: Om
 permalink: /om/
 ---
 
-Mitt navn er Øyvind Skaaden. Jeg er 22 år gammel og studerer Elektronisk systemdesign og innovasjon på NTNU.
+Mitt navn er Øyvind Skaaden. Jeg er 21 år gammel og studerer Elektronisk systemdesign og innovasjon på NTNU.
-
-Jeg er stor fan av open-source og prøver så godt jeg kan å fremme dette. 
-
-Jeg har både en [github](https://github.com/oyvindskaaden) og en [personlig git](https://git.glados.no/).

assets/css/components/theme.css

@@ -102,7 +102,6 @@ blockquote {
 
 a {
   color: var(--link-color);
-  text-decoration: none;
 }
 
 a:hover {

assets/css/home.css

@@ -27,13 +27,7 @@
   min-height: calc(100vh - 47.75rem);
 }
 
-/*
+.home-link>a {
-.home-link a{
-  text-decoration: none;
-}
-*/
-
-a.home-link:hover{
   text-decoration: none;
 }
 

index.html

@@ -7,12 +7,12 @@ description: Personlig nettside for Øyvind Skaaden. Inneholder det meste av per
   <div class="row">
     {% for home in site.data.home %}
     <div class="col-md-4">
-      <a class="home-link" href="{{ home.href }}">
+      <a href="{{ home.href }}">
         <div class="icon">
           <i class="fas {{ home.icon }}"></i>
         </div>
-        <h3 class="no-anchor home-link">{{ home.title }}</h3>
       </a>
+      <h3 class="no-anchor home-link"><a class="" href="{{ home.href }}">{{ home.title }}</a></h3>
       <p>{{ home.description }}</p>
     </div>
     {% endfor %}

ntnu/21v/tfe4130/lectures/2021-01-14/2021-01-14.md

@@ -1,24 +0,0 @@
----
-layout: layouts/lecture
-title: "TFE4130"
-description: "1D Bølger forts."
-date: "2021-01-14"
-math: true
----
-
-## Akustisk impedanse
-
-## Akustisk intensitet
-
-$$ \boldsymbol{I} = \frac{1}{T}\int_0^T p_\text{real}\boldsymbol{v}_\text{real}(t) dt $$
-
-FOr en planbølge
-
-$$ I_x = \frac{p_\text{rms}}{p_x c}$$
-
-## Refleksjon og transmisjon
-
-Dersom en børge beveger seg over en grenseflate mellom to forskjellige impedanser.
-
-* Trykket nå være kontinuerlig over grenseflaten
-* Farten over grenseflaten må være konstant.

ntnu/21v/tfe4130/tfe4130.md

@@ -4,12 +4,6 @@ title: "TFE4130"
 description: "Bølgeforplantning"
 ---
 
-## Filer og annet
-
-Alle øvinger og andre viktige filer ligger på [git](https://git.glados.no/oyvindskaaden/TFE4130).
-
 ## Forelesninger
 
-[2021-01-12](./lectures/2021-01-12/) - Intro
+[2021-01-12](./lectures/2021-01-12/) - Intro
-
-[2021-01-14](./lectures/2021-01-14/) - Bølger forts.

ntnu/21v/ttk4145/summary/summary.md

@@ -1,200 +0,0 @@
----
-title: "Oppsumering av TTK4145"
-description: "Lot of theory and discussion, some fomulas, spring 2021."
-date: 2021-05-04
-math: true
----
-
-## Fault tolerance
-
-Hard to capture faults. 
-
-
-### Bugs
-
-* 1 bug per 50 lines before testing
-* 1 bug per 500 at release
-* 1 bug per 550 after a year, the constant
-
-1. Make the program work within specs.
-2. Run/Tests of the program-
-3. Errors happen
-4. Locate errors
-    * Incomplete spec
-    * Missing handleling of som situation
-5. Fix code
-
-### Traditional error handeling
-
-{% highlight c %}
-FILE *
-openConfigFile(){
-    FILE * f = fopen("/path/to/config.conf");
-    if (f == NULL) {
-        switch(errno){
-            case ENOMEM: {
-                ...
-                break;
-            }
-            case ENOTDIR: {
-                ...
-                break;
-            }
-            // Do this for all errors
-        }
-    }
-}
-{% endhighlight %}
-
-### Causes of errors
-
-* Incomplete specification
-* Software bugs
-* HW problems
-* Communication problems
-
-### Fault tolerance in real time systems
-
-The problem with traditional errorhandleing is that errors can happen at any possible time.
-This is extremely hard to test. 
-
-This is some of the error handling real time programming have.
-
-* Handling of unexpected errors
-* More threads hanles errors
-* Can not test the conventional way
-  * Can only show extistence of errors
-  * Can not find errors in specification
-  * Can not find race conditions
-
-The fault path is shown under.
-
-![Fault tolerance](figures/fault-path.svg)
-
-With fault tolerance the path looks something more like the figure under.
-
-![Fault tolerance](figures/fault-tolarance.svg)
-
-### Error handling
-
-Keep it simple!
-
-The error modes is a part of the module interface.
-
-One way is to handle all errors the same way.
-Handle the as if it was the worst error.
-Crash and start again.
-
-A different approach is to check that everything is OK.
-
-To test how the systems responds for a unknown error is to insert a failed acceptance test (a not OK signal).
-
-### Redundancy
-
-* If I have $N$ copies of my data, it is possible to handle that one is destroyed.
-* Sending $N$ messages, trying $N$ times.
-
-**Static redundancy**
-
-* $N$ active copies. Sending $N$ messages if it is necessary or not.
-* Detecting errors is not important.
-* Handles cosmic rays easily.
-
-**Dynammic redunancy**
-
-* Relies on detecting the error and recovering
-  * Resend if timeout and not receiving "ack"
-  * Go with default if no messages have been received
-* The acceptancetest must be good.
-
-
-### Fault model
-
-#### Example with storage functions.
-
-**Step 1: Failure modes**
-
-Find the failure modes: What could go wrong?
-
-* **Write**: May return "I failed". Does not know why it faield
-* **Read**: May return "I failed". Does not know why it failed.
-
-**Step 2: Detect, Simplify, Inject errors**
-
-* Write information on where/what/how the process is doing.
-* All errors --> Fail
-* Inject errors
-
-**Step 3: Handling with redundancy**
-
-* Have multiple copies of the the information
-  * Use only the newest
-
-#### Example with communication function
-
-**Step 1: Failure modes**
-
-* Message
-  * Lost
-  * Delayed
-  * Corrupted
-  * Duplicated
-  * Wrong recipient
-
-**Step 2: Detection, Merging of errormodes and error injection**
-
-* Adding information to message
-  * Checksum
-  * Session ID
-  * Sequence number
-* Adding "ack" on well recieved messages
-* All errors will be treaded as "Lost message"
-* Injection
-  * Occasionally throw away some messages
-
-**Step 3: Handling with redundancy**
-
-* Timeout 
-* Retransmit message
-
-#### Example with processes and caculations
-
-A calculation is an abstract, so how can we talk generally about the failure modes.
-
-**Step 1: Failure modes**
-
-One failure mode
-
-**Step 2: Detect, simplify, inject errors**
-
-All failed acceptance tests will "PANIC" or "STOP".
-
-**Step 3: Handling with redundancy**
-
-There are three solutions:
-
-1. Checkpoint restart
-    * Do all the work incuding the acceptance test
-    * Wait with the "side effects"
-    * Store a checkpoint
-    * Do the "side effects"
-2. Process pairs
-    * Crash and let an another process take over
-3. Presistent processes
-
-
-## Transactions
-
-A transaction is a design framework for Damage Confinement and Error Recovery.
-
-* An *atomic action*, just without the backward recovery error mode as standard mode
-* invincible and instantaneous "calculation" seen from the outside
-* A transformation from one consistent state to another'
-* A modular computation
-
-### Four features: ACID
-
-* **A**tomicity: Either all side effects happens or none
-* **C**oncistency: Leaves the system in a consistent state when finished
-* **I**solation: Errors does not spread
-* **D**urability: Results are not lost

ntnu/21v/ttk4145/ttk4145.md

@@ -1,15 +0,0 @@
----
-layout: layouts/list
-title: "TTK4145"
-description: "Sanntidsprogrammering"
----
-
-## Oppsummering
-
-[Oppsummering](summary/) av faget TTK4145.
-
-## Prosjekt
-
-## Øvinger
-
-

ntnu/21v/ttt4280/lab/1/1.md

@@ -1,34 +0,0 @@
----
-layout: layouts/lecture
-title: "TTT4280"
-description: "Labforelesning 1"
-date: "2021-01-18"
-math: false
----
-
-## Laboratorium
-
-### System
-
-* Raspberry Pi
-* Linux
-* A/D omformere
-* Python
-
-### Oppgaver
-
-* Systemoppsett
-  * Klargjøre rPi og instrumenteringskrets
-* Akustikk
-  * Beregne retning til lydkilde
-* Radar
-  * Doppler
-* Optikk
-
-## Laboppgave 1
-
-1. Tegne blokkdiagram
-2. Studere datablat for ADC
-3. Drøfte fordeler med DMA
-
-![Blokk](figures/TTT4280%20-%20Lab%20Blokk.png)

ntnu/21v/ttt4280/lectures/2021-01-18/2021-01-18.md

@@ -1,8 +0,0 @@
----
-layout: layouts/lecture
-title: "TTT4280"
-description: "Usikkerhet og feilforplantning"
-date: "2021-01-18"
-math: true
----
-

ntnu/21v/ttt4280/ttt4280.md

@@ -8,5 +8,3 @@ description: "Sensorer og instrumentering"
 
 [2021-01-11](./lectures/2021-01-11/) - Intro og målesikkerhet
 
-[2021-01-18](./lectures/2021-01-18/) - Usikkerhet og feilforplantning
-