1. 처리량(throughput)  up - 정해진 시간 내에서 처리할 수 있는 작업량, 처리 개수

2. 반환시간(turn around time) down - 컴퓨터 센터에 작업을 지시하고 나서부터 결과를 받을 때 까지 경과 시간이다.

대기시간 + 실험시간 = 반환시간 , 첫번째 반응하는 시간이 응답시간(reponse time)이라고 한다. 

3. 신뢰도(reliability) up - 시스템이 주어진 문제를 얼마나 정확하게 해결하는가를 나타내는 척도

4. 이용 가능도(availability) up - 잔여량은 컴퓨터 시스템 내에 사용 가능한 자원에 관한 정보 표현이다. 

5. 병목 현상(bottleneck) down - 시스템 자원이 용량에 있어서 최대 한계에 도달시 발생될 수 있다.

bench mark program - 컴퓨터 시스템이나 cpu, 운영체제 등의 전박적인 성능을 측정하는 프로그램

'ETC' 카테고리의 다른 글

운영체제의 계층 구조  (0) 2020.03.12
다중 프로그래밍 방식에서의 시간  (0) 2020.03.12
운영체제의 정의 및 목표 (3/11/2020)  (0) 2020.03.11
IP 주소(3/11/2020)  (0) 2020.03.11
Checked vs Unchecked  (0) 2020.03.05

하드웨어를 제어하는 시스템 소프트웨어 

1. 시스템 s/w(관리 프로그램) <-> 응용 s/w(게임, 카톡)

2. 자원을 관리한다 : 

- h/w : cpu 메모리 i/o

process - 실행중인 프로그램

prcoessor - 처리하는, cpu 중앙처리장치

- s/w : system software, game etc

3. 사용자의 편이성

4.  초기 -> rom

현재는 -> ram으로 올리는데, 디스크는 이제 rom역할을 하면서 디스크에 있는 것을 램에 올리면 boot strapping loader 보 -> 주 올리는 방식. rom은 아직도 사용한다. 

memory = read only memory 전원이 있는 없든 계속 유지 비휘발성, random acess memory 임시저장 휘발성. 

펌웨어 = 기계 + sw -> rom

램에 프로그램을 올리면 process 실행중이다. 

주 기억장치, 보조 기억장치

rom안에 있는 기초 필요한 것들 : post(자기자신 점검), rom-bios, bootstrapping(c drive에 있는 것을 boot하는 역할)

basic input out system bios

5. ms-windows - close system

unix, linux - open system c language

단일 프로그래밍, 다중 프로그래밍(필요한 요소, 처리량, 신뢰성, 반환시간 turn around time, 가용성 == bench mark)

프로세스 스케줄링

 

 

'ETC' 카테고리의 다른 글

다중 프로그래밍 방식에서의 시간  (0) 2020.03.12
운영체제 시스템의 성능 평가 척도  (0) 2020.03.11
IP 주소(3/11/2020)  (0) 2020.03.11
Checked vs Unchecked  (0) 2020.03.05
Git  (0) 2020.03.04

IP 주소는 ipv4 그리고 ipv6가 있다. 

ipv4는 32bit, xxx.xxx.xxx.xxx, 각 xxx가 8bit를 가지고 있어서 32bit체계이다. 

2^32를 하면  4294967296, 의 아이피를 가질 수 있지만 현재로서는 턱없이 부족한 수여서 ipv6, 126bit를 가진 ip를 만들었다. 

하지만 공유기를 통해 많은 아이피를 사용할 수 있게됐다. 

 

ip는 a,b,c,d,e클래스가 존재하며, 현재는 a,b,c만 사용한다. 

클래스 상위비트 상위 8비트 클래스범위
a 0 00000000~01111111 0.0.0.0 ~ 127.0.0.0
b 10 10000000~10111111 128.0.0.0 ~ 191.0.0.0
c 110 11000000~11011111 192.0.0.0 ~ 223.0.0.0

c클래스 같은 경우에는 xxx.xxx.xxx가 네트워크고 마지막 3개 xxx는 호스트이다. 즉 0~255 256개의 아이피를 줄 수 있는데, 첫번째 0은 대표 주소이며 마지막 255은 브로드캐스팅 주소이다. 그래서 정확하게는 254개의 아이피를 가질수 있다. 

cidr(classless inter-domain routing) - 만약 203.42.115.0 아이피를 유저한테 부여하면, 해당 유저는 255개의 아이피를 사용할 수 있는데, 정작 사용하는 아이피는 3~4개 밖에 안될 수 있다. 이런 비효율적인 아이피 방식을 개선하기 위해서 나온 방법이 cidr이다. c class같은 경우에는 xxx.xxx.xxx.??? 에 xxx는 네트워크 주소로 사용하여 총 24비트를 사용한다. 그래서 xxx.xxx.xxx.??? / 30이렇게 부여하면 총 30비트를 네트워크 주소로 사용한다는 뜻이므로 2티만 호스트 주소로 사용한다는 뜻이다. 2 bit = 4가지, 하나는 대표 주소, 마지막 하나는 브로드캐스팅 주소, 즉 2개만 사용가능.

dhcp(dynamic host configuration protocol) - 

 

nat(network address translation) - 사설 아이피 주소를 공인 아이피 주소로 바꿔주는 주소 변환기이다. 

'ETC' 카테고리의 다른 글

운영체제 시스템의 성능 평가 척도  (0) 2020.03.11
운영체제의 정의 및 목표 (3/11/2020)  (0) 2020.03.11
Checked vs Unchecked  (0) 2020.03.05
Git  (0) 2020.03.04
Design ToolBox  (0) 2020.02.29

'ETC' 카테고리의 다른 글

운영체제의 정의 및 목표 (3/11/2020)  (0) 2020.03.11
IP 주소(3/11/2020)  (0) 2020.03.11
Git  (0) 2020.03.04
Design ToolBox  (0) 2020.02.29
Chapter 2  (0) 2020.02.28

https://github.github.com/training-kit/downloads/github-git-cheat-sheet/

https://try.github.io/

Git branches are simply pointers pointing to a specific command. 

 

Branch early, and branch often.

 

rebase in git

 

HEAD - symbolic name for currently checked out commit. always points to the most recent commit. 

instead of checking out to a branch, you could check out towards specific commit. 

 

Caret(^) - travels to parent version

 

Tilde(~) - travles specific number of parents 

 

git branch -f master HEAD~3 = =        move master branch to head + 3

 

reversing changes in git::

git reset - works great in local repository, going back to rewrite history

 

git revert  - works great for remote repository, git revert creates a new commit of the previous version, allowing you to push to other checkouts. 

 

 

 

 

Above commands should cover 90% of vcs(version control system) while 10% will help in more flexible precise ways.

 

cherry-pick

 

git rebase -i HEAD~4, omit and pick 

use tag for version display 

 

'ETC' 카테고리의 다른 글

IP 주소(3/11/2020)  (0) 2020.03.11
Checked vs Unchecked  (0) 2020.03.05
Design ToolBox  (0) 2020.02.29
Chapter 2  (0) 2020.02.28
Chapter 1  (0) 2020.02.27

object composition - composition simple defines HAS-A relation. For example, abstract factory pattern uses object composition, having many interfaces in the abstract factory showing a has-a relationship. 

 

OO Basics 

 - Abstraction

 - Encapsulation - wrapping up of data under a single unit. (varies variables under a class)

 - Polymorphism - the ability of an object to take on many forms. (person, employee, boss)

 - Inheritance

 

OO Principles 

 - Encapsulate what varies -

 

Take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't. (chapter 1, duck flying and quack behavior)

(Hide the potentional change inside the interface. When things change, the function inside the interface might need to change but software written using the interface does not.) 

 

 - Favor composition over inheritance -

Inheritance is abstract concept while composition is actual existing component. Implementing a class cannot be changed during runtime while compositions can be changed and be used dynamically. (See design pattern strategy pattern's strategy part of strategy vs concept)

 

 - Program to interfaces(supertype), not implementations -

 

the declared type of the variables should be a supertype, usually an abstract class or interfact, so that the objects assigned to those variables can be of any concrete implementation of the supertype. 

 

Instead of creating a class and implementing it, create a seperate interface or abstract and sets of classes for certain behaviors. (ex. Duck flying behavior in chapter 1)

(use interface for polymorphism reasons etc not for its implementations. )

 

Programming to an implementation would be :

Dog d = new Dog();

 

Programing to an interface/supertype : 

Animal animal = new Dog(); 

 

assign the concrete implementation object a runtime :

a = getAnimal();

a.makeSound();

 

 - Strive for loosely coupled designs between objects that interact

 - Depend on abstractions. Do not depend on concrete classes. (Dependency Inversion Principle)

 

OO patterns 

 - Strategy : defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 

 - Observer : defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 

 - Decorator : attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. 

 - Abstract Factory : Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

 - Factory Method : Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to the subclasses. 

- Singleton : Ensure a class only has one instance and provide a global point of access to it. 

'ETC' 카테고리의 다른 글

Checked vs Unchecked  (0) 2020.03.05
Git  (0) 2020.03.04
Chapter 2  (0) 2020.02.28
Chapter 1  (0) 2020.02.27
HLS vs DASH  (0) 2020.02.24

Observer pattern can be visualized as newspaper subscription service with its publishers and subscribers.

 

the subject is the publisher, observers are the subscribers.

 

The observer pattern - defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. 

 

Design principles : Strive for loosely coupled designs between objects that interact

'ETC' 카테고리의 다른 글

Git  (0) 2020.03.04
Design ToolBox  (0) 2020.02.29
Chapter 1  (0) 2020.02.27
HLS vs DASH  (0) 2020.02.24
Sites to view later  (0) 2020.02.24

https://github.com/Tonyzorz/HeadFirstDesignPattern

 

Tonyzorz/HeadFirstDesignPattern

Head first design pattern. Contribute to Tonyzorz/HeadFirstDesignPattern development by creating an account on GitHub.

github.com

Design principles:

- Identify the aspects of your application that vary and separte them frmo what stays the same.

- Program to an interface, not an implementation. 

- Favor composition over inheritance. 

 

Strategy pattern : defines a family of algorithms, encapsulate each one, and makes them interchangeable. Strategy lets the algoirthm vary indepdently from clients that use it. 

 

Design pattern gives you shared vocabulary with other developers. Also allows you to view things in pattern ways instead of object way. 

'ETC' 카테고리의 다른 글

Design ToolBox  (0) 2020.02.29
Chapter 2  (0) 2020.02.28
HLS vs DASH  (0) 2020.02.24
Sites to view later  (0) 2020.02.24
Media files note 1  (0) 2020.02.24

+ Recent posts