shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
다음 마이크로컨트롤러는 Cortex-M0+ 코어를 기반으로 한다.
다음 칩은 Cortex-M0+를 보조 코어로 사용한다.
가장 작은 ARM 마이크로컨트롤러는 Cortex-M0+ 유형이다 (2014년 현재, [[칩 스케일 패키지]]에서 1.6 mm x 2 mm로 가장 작은 것은 Kinetis KL03이다).
2018년 6월 21일, "[[마이크로컨트롤러#가장 작은 컴퓨터|세계에서 가장 작은 컴퓨터]]" 또는 컴퓨터 장치가 발표되었다 [[미시간 대학교]] 연구원들이 2018년 VLSI 기술 및 회로 심포지엄에서 "A 0.04mm3 16nW 무선 및 배터리 없는 센서 시스템, 통합 Cortex-M0+ 프로세서 및 셀룰러 온도 측정을 위한 광통신" 논문과 함께 ARM Cortex-M0+를 기반으로 한 (RAM 및 [[무선 네트워킹|태양광 발전]] 기반의 무선 송수신기를 포함한) 장치이다. 이 장치는 2018년 3월에 IBM이 이전에 주장했던 세계 기록 크기 컴퓨터보다 10분의 1 크기로, 소금 알갱이보다 작다.
Cortex-M1.
Cortex-M1은 [[FPGA]] 칩에 로드되도록 특별히 설계된 최적화된 코어이다.
Cortex-M1 코어의 주요 기능은 다음과 같다.
다음 공급업체는 Cortex-M1을 FPGA 칩의 소프트 코어로 지원한다.
Cortex-M3.
[[파일:ArduinoDue Front.jpg|thumb|300px|right|아트멜 ATSAM3X8E ([[ARM Cortex-M3]] 코어) 마이크로컨트롤러가 장착된 [[아두이노]] Due 보드]]
[[파일:LPCXpresso DevelopmentBoard with NXP LPC1343 (ARM Cortex-M3) MCU.jpg|thumb|300px|[[NXP 반도체|NXP]] LPC1343이 장착된 LPCXpresso 개발 보드]]
Cortex-M3 코어의 주요 기능은 다음과 같다.
다음 마이크로컨트롤러는 Cortex-M3 코어를 기반으로 한다.
다음 칩은 Cortex-M3를 보조 코어로 사용한다.
다음 FPGA에는 Cortex-M3 코어가 포함되어 있다.
다음 공급업체는 Cortex-M3를 FPGA 칩의 소프트 코어로 지원한다.
Cortex-M4.
[[파일:Energy Micro Woder Gecko STK showing EFM32WG990F256 (ARM Cortex-M4F) MCU.JPG|thumb|right|Silicon Labs ([[Energy Micro]]) Wonder Gecko STK Board with [[EFM32]]WG990]]
[[파일:TI Stellaris Launchpad showing LM4F120H (ARM Cortex-M4F) MCU.JPG|thumb|[[텍사스 인스트루먼트|TI]] LM4F120이 장착된 Stellaris Launchpad 보드]]
개념적으로 Cortex-M4는 Cortex-M3에 [[디지털 신호 처리 장치|DSP]] 명령어와 선택적 [[부동소수점 장치]] (FPU)를 더한 것이다. FPU가 있는 코어는 Cortex-M4F로 알려져 있다.
Cortex-M4 코어의 주요 기능은 다음과 같다.
[[파일:Micro-bit v2 (cropped) nRF52833.JPG|thumb|upright|[[micro:bit|마이크로 비트]] v2의 nRF52833]]
[[파일:Embedded World 2016, M32F407 (cropped) STM M32F407IG.jpg|thumb|upright|STM32F407IGH6]]
다음 마이크로컨트롤러는 Cortex-M4 코어를 기반으로 한다.
다음 마이크로컨트롤러는 Cortex-M4F (M4 + [[부동소수점 장치|FPU]]) 코어를 기반으로 한다.
다음 칩은 Cortex-M4 또는 M4F를 보조 코어로 사용한다.
Cortex-M7.
[[파일:Arduino Giga R1 WiFi.png|thumb|302x302px|Arduino GIGA R1 WiFi 보드와 (듀얼 코어 ARM Cortex-M7 + ARM Cortex-M4) STM32H747XIH6 마이크로컨트롤러]]
Cortex-M7은 이전 Cortex-M4보다 거의 두 배의 전력 효율을 가진 고성능 코어이다. [[분기 예측]]을 포함한 6단계 [[슈퍼스칼라]] 파이프라인과 단정밀도 및 선택적으로 [[배정밀도 부동소수점수|배정밀도]] 연산이 가능한 선택적 [[부동소수점 장치]]를 특징으로 한다. 명령어 및 데이터 버스는 이전 32비트 버스에서 64비트 폭으로 확장되었다. 코어에 FPU가 포함되어 있으면 Cortex-M7F로 알려져 있고, 그렇지 않으면 Cortex-M7이다.
Cortex-M7 코어의 주요 기능은 다음과 같다.
다음 마이크로컨트롤러는 Cortex-M7 코어를 기반으로 한다.
Cortex-M23.
Cortex-M23 코어는 2016년 10월에 발표되었으며, 2015년 11월에 이전에 발표된 [[ARM 아키텍처#Armv8-R 및 Armv8-M|ARMv8-M 아키텍처]]를 기반으로 한다. 개념적으로 Cortex-M23은 Cortex-M0+와 유사하며, 정수 나눗셈 명령어와 TrustZone 보안 기능이 추가되었고, 2단계 [[명령어 파이프라인]]도 가지고 있다.
Cortex-M23 코어의 주요 기능은 다음과 같다.
다음 마이크로컨트롤러는 Cortex-M23 코어를 기반으로 한다.
Cortex-M33.
Cortex-M33 코어는 2016년 10월에 발표되었으며, 2015년 11월에 이전에 발표된 [[ARM 아키텍처|ARMv8-M 아키텍처]]를 기반으로 한다. 개념적으로 Cortex-M33은 Cortex-M4와 Cortex-M23의 교차점과 유사하며, 3단계 [[명령어 파이프라인]]도 가지고 있다.
Cortex-M33 코어의 주요 기능은 다음과 같다.
다음 마이크로컨트롤러는 Cortex-M33 코어를 기반으로 한다.
다음 칩은 Cortex-M33 또는 M33F를 보조 코어로 사용한다.
Cortex-M35P.
Cortex-M35P 코어는 2018년 5월에 발표되었으며 [[ARM 아키텍처|Armv8-M 아키텍처]]를 기반으로 한다. 이는 새로운 명령어 캐시와 ARM SecurCore 제품군에서 가져온 새로운 변조 방지 하드웨어 개념, 구성 가능한 패리티 및 ECC 기능을 추가한 Cortex-M33 코어로 볼 수 있다.
현재 Cortex-M35P에 대한 정보는 기술 참조 매뉴얼 및 일반 사용자 가이드가 아직 출시되지 않았기 때문에 제한적이다.
다음 마이크로컨트롤러는 Cortex-M35P 코어를 기반으로 한다.
Cortex-M52.
Cortex-M52 코어는 2023년 11월에 발표되었으며 [[ARM 아키텍처|Armv8.1-M 아키텍처]]를 기반으로 한다. 개념적으로는 Cortex-M33과 Cortex-M55의 교차점으로 볼 수 있다. 주요 차이점은 Helium 코프로세서가 단일 비트(M55는 듀얼 비트)이며, 애플리케이션 전환을 용이하게 하기 위해 M33과 유사한 32비트 메인 버스를 가지고 있다는 것이다. 4단계 명령어 파이프라인을 가지고 있다.
Cortex-M52 코어의 주요 기능은 다음과 같다.
다음 마이크로컨트롤러는 Cortex M52 코어를 기반으로 한다.
Cortex-M55.
Cortex-M55 코어는 2020년 2월에 발표되었으며 [[ARM 아키텍처|Armv8.1-M 아키텍처]]를 기반으로 한다. 4단계 또는 5단계 명령어 파이프라인을 가지고 있다.
Cortex-M55 코어의 주요 기능은 다음과 같다.
Cortex-M85.
Cortex-M85 코어는 2022년 4월에 발표되었으며 [[ARM 아키텍처|Armv8.1-M 아키텍처]]를 기반으로 한다. 7단계 명령어 파이프라인을 가지고 있다.
ARM 칩에 대한 문서는 광범위하다. 과거에는 8비트 마이크로컨트롤러 문서가 일반적으로 단일 문서에 담겼지만, 마이크로컨트롤러가 진화함에 따라 이를 지원하는 데 필요한 모든 것도 진화했다. ARM 칩의 문서 패키지는 일반적으로 IC 제조업체와 CPU 코어 공급업체([[Arm 홀딩스|ARM 리미티드]])의 문서 모음으로 구성된다.
일반적인 하향식 문서 트리는 다음과 같다.
IC 제조업체는 평가 보드 사용자 매뉴얼, 애플리케이션 노트, 시작 가이드, 소프트웨어 라이브러리 문서, 오류 정정(errata) 등 추가 문서를 가지고 있다. 공식 Arm 문서 링크는 [[#외부 링크|외부 링크]] 섹션을 참조한다.
[[분류:32비트 마이크로프로세서]]
[[분류:ARM 마이크로프로세서]]
아르고너트 RISC 코어(Argonaut RISC Core, ARC)는 원래 ARC 인터내셔널이 설계한 32비트 및 64비트 RISC 중앙 처리 장치(CPU) 제품군이다.
ARC 프로세서는 스토리지, 디지털 홈, 모바일, 자동차, 사물인터넷(IoT) 애플리케이션을 포함한 광범위한 시스템 온 칩(SoC) 장치에 사용하기 위해 구성 및 확장이 가능하다. 200개 이상의 조직에서 라이선스를 취득했으며 매년 15억 개 이상의 제품에 탑재된다.
ARC 프로세서는 임베디드 및 호스트 SoC 애플리케이션을 위한 우수한 성능과 코드 밀도를 제공하는 16/32비트 ARCompact 압축 명령어 집합 명령어 집합(ISA)을 사용한다.
ARC 개념은 원래 슈퍼 패미컴용 슈퍼 FX 칩으로 시작된 일련의 3D 파이프라인 개발 프로젝트를 통해 아르고너트 게임스 내에서 개발되었다.
1995년, 아르고너트는 다양한 기술 프로젝트를 수행하는 아르고너트 테크놀로지스 리미티드(ATL)와 아르고너트 소프트웨어 리미티드(ASL)로 분할되었다.
1996년 초, 아르고너트의 총책임자인 존 에델슨은 BRender 및 모션 캡처와 같은 ATL 프로젝트를 축소하고 ARC 개념 개발에 투자하기 시작했다. 1996년 9월, 릭 클루카스는 ARC 프로세서의 가치가 아르고너트가 이를 사용하는 프로젝트를 수행하는 것보다 다른 사람들이 이를 사용하는 데 있다고 판단하고 밥 테르윌리거에게 CEO로 합류할 것을 요청했다. 릭 클루카스는 이후 CTO 역할을 맡았다.
1997년, 아팍스 파트너스의 투자에 이어 ATL은 ARC 인터내셔널이 되었고 아르고너트 게임스에서 완전히 독립했다. 골드만삭스와 5개 다른 투자 은행의 인수 보증을 받아 런던 증권거래소에 기업공개를 하기 전에 세 개의 관련 기술 회사(캘리포니아주 샌타크루즈의 MetaWare(개발 및 모델링 소프트웨어), 뉴햄프셔주 내슈아의 VAutomation(주변 반도체 IP), 온타리오주 니핀의 Precise Software(RTOS))를 인수했다.
2009년, ARC 인터내셔널은 비라지 로직에 인수되었다. 2010년, 비라지는 시높시스에 인수되었고 ARC 프로세서는 시높시스 디자인웨어 시리즈의 일부가 되었다.
2020년 4월, 시높시스는 64비트 지원을 포함하는 ARCv3 ISA를 출시했다.
2023년 11월, 시높시스는 ARC 제품군의 확장으로 RISC-V 호환 ARC-V 프로세서 IP를 출시했다.
설계 구성.
설계자는 특허받은 구성 기술을 사용하여 각 ARC 프로세서 인스턴스를 특정 성능, 전력 및 영역 요구 사항에 맞게 조정함으로써 제품을 차별화할 수 있다.
ARC 프로세서의 구성은 ARChitect 프로세서 구성기를 사용하여 설계 시점에 이루어진다. 코어는 확장 가능하도록 설계되어 설계자가 성능을 크게 향상시키거나 전력 소비를 줄일 수 있는 자체 사용자 지정 명령어를 추가할 수 있다.
대부분의 임베디드 마이크로프로세서와 달리 추가 명령어, 레지스터 및 기능을 모듈식으로 추가할 수 있다. 고객은 작업을 분석하고, 작업을 세분화한 다음 적절한 확장을 선택하거나 자체 확장을 개발하여 자체 사용자 지정 마이크로프로세서를 만든다. 속도, 에너지 효율 또는 코드 밀도를 최적화할 수 있다. 확장에는 예를 들어 메모리 관리 장치(MMU), 고속 곱셈-누산기, USB 호스트, 비터비 경로 디코더 또는 사용자의 독점적인 RTL 기능이 포함될 수 있다.
프로세서는 합성 가능하며 모든 파운드리 또는 프로세스에서 구현할 수 있으며 완전한 개발 도구 스위트가 지원된다.
시스리눅스 프로젝트(The Syslinux Project)는 컴퓨터에서 리눅스 배포판을 시작하기 위한 다섯 가지 부트로더 스위트로, 현재는 개발이 중단되었다. 주로 H. 피터 안빈이 개발했다.
시스리눅스 프로젝트는 여섯 가지 다른 부트로더로 구성되어 있다:
이 프로젝트에는 두 가지 별도의 메뉴 시스템과 추가 모듈 개발 환경도 포함되어 있다.
SYSLINUX와 ISOLINUX.
SYSLINUX는 원래 복구 플로피 디스크, 라이브 USB 또는 기타 경량 환경을 위한 것이었다. ISOLINUX는 라이브 CD 및 리눅스 설치 CD를 위한 것이다.
SYSLINUX 부트로더는 USB 스틱과 같은 단일 소스에서 여러 배포판을 부팅하는 데 사용될 수 있다.
콤팩트 디스크에서 부팅할 때 약간의 복잡성이 따른다. 엘 토리토 표준은 두 가지 다른 모드에서 부팅을 허용한다:
이러한 선택권은 때때로 유용하다. 왜냐하면 ISOLINUX는 바이오스 버그에 취약하기 때문이다. 그렇기 때문에 SYSLINUX를 사용하여 부팅할 수 있다는 것은 편리하다. 이는 주로 1999년 이전에 제작된 컴퓨터에 영향을 미치며, 사실 현대 컴퓨터의 경우 "에뮬레이션 없음" 모드가 일반적으로 더 안정적인 방법이다. 버전 3.72부터 ISOLINUX는 소위 "하이브리드 ISO" 이미지 생성을 지원하며, 이는 콤팩트 디스크의 엘 토리토 부팅 레코드와 하드 디스크의 마스터 부트 레코드를 ISO 이미지에 담는다. 이 하이브리드 이미지는 콤팩트 디스크 또는 USB 플래시 드라이브 모두에 쓸 수 있다.
PXELINUX.
PXELINUX는 네트워크 인터페이스 컨트롤러 (NIC)의 PXE 호환 ROM과 함께 사용되어 근거리 통신망을 통해 부트스트랩 프로그램을 수신할 수 있도록 한다. 이 부트스트랩 프로그램은 운영체제 커널을 로드하고 구성하여 사용자가 컴퓨터를 제어할 수 있게 한다. 일반적으로 PXELINUX는 중앙 네트워크 서버에서 리눅스 설치를 수행하거나 디스크 없는 워크스테이션을 부팅하는 데 사용된다.
EXTLINUX.
EXTLINUX는 LILO 또는 GRUB과 유사한 범용 부트로더이다. 시스리눅스 4부터 EXTLINUX는 Btrfs, FAT, NTFS, UFS/UFS2 및 XFS 파일 시스템을 처리할 수 있다.
EFILINUX.
EFILINUX는 UEFI에서 부팅하도록 설계된 SYSLINUX 부트로더의 확장 버전이지만, 다른 부트로더로 체인 로딩을 지원하지 않는 등의 몇 가지 제한 사항이 있다.
COMBOOT.
SYSLINUX는 C 또는 어셈블리 언어로 작성된 COMBOOT 모듈을 통해 확장될 수 있다. 32비트 모듈은 일반적으로 codice_1 파일 확장자를 사용한다. 버전 5 이상은 16비트 codice_2 모듈을 지원하지 않는다.
하드웨어 감지 도구 (HDT).
3.74 릴리스부터 Syslinux 프로젝트는 GNU GPL 약관에 따라 라이선스된 하드웨어 감지 도구 (HDT) 프로젝트를 호스팅한다. 이 도구는 모든 IA-32 호환 시스템에 대한 저수준 정보를 표시하는 32비트 모듈이다. 명령줄 인터페이스와 반그래픽 메뉴 모드를 모두 제공하여 탐색할 수 있다. HDT는 부팅 가능한 ISO 및 2.88MB 플로피 디스크 이미지로도 제공된다. HDT의 마지막 업데이트는 2015년이었고, 그 이후로 개발이 중단되었다.
오픈RC(OpenRC)는 유닉스 계열 운영체제를 위한 의존성 기반의 Init 시스템이다. 이는 젠투 리눅스 프로젝트에서도 활동한 NetBSD 개발자 로이 마플스가 만들었다.
오픈RC는 다음의 기본 Init 시스템 또는 프로세스 관리자이다.
오픈RC는 다음의 Init 시스템 또는 프로세스 관리자로 사용할 수 있다.
오픈RC는 여러 모듈식 구성 요소로 이루어져 있으며, 주요 구성 요소는 init(선택 사항), 핵심 의존성 관리 시스템, 데몬 관리자(선택 사항)이다. C와 POSIX 호환 셸로 작성되어 BSD 및 리눅스 시스템에서 사용할 수 있다.
오픈RC의 핵심 부분은 의존성 관리 및 init 스크립트 파싱을 처리한다. 오픈RC는 런레벨을 스캔하고, 의존성 그래프를 구축한 다음, 필요한 서비스 스크립트를 시작하여 작동한다. 스크립트가 시작되면 종료된다. 기본적으로 오픈RC는 데몬 관리를 위해 start-stop-daemon의 수정된 버전을 사용한다.
Init 스크립트는 SysVinit에서 사용되는 스크립트와 유사하지만, 스크립트 생성을 단순화하는 여러 기능을 제공한다. 스크립트는 , , 를 가지고 있다고 가정하며, 시스템은 이미 선언된 변수를 사용하여 기본 함수를 생성한다. depend 함수는 SysVinit에서 LSB 헤더로 수행될 다른 서비스에 대한 의존성을 선언하는 데 사용된다. 구성과 메커니즘은 conf.d 디렉토리의 구성 파일과 init.d 디렉토리의 init 파일로 분리된다.
openrc-init은 버전 0.25에서 의 선택적 대체품으로 처음 등장했다. 이는 젠투 리눅스의 기본 init 시스템인 SysVinit을 대체할 수 있다.
Supervise-daemon은 OpenRC에 감독 기능을 부여하며 버전 0.21에서 처음 등장했다. supervise-daemon이 데몬을 시작하고 모니터링하도록 init 스크립트에서 활성화할 수 있다. Runit 및 s6을 포함한 여러 다른 데몬 감독자가 지원된다.
ratpoison은 숀 베츠가 주로 개발한 X 윈도 시스템용 타일링 창 관리자이다. 사용자 인터페이스와 대부분의 기능은 GNU Screen 터미널 다중화기에서 영감을 얻었다. ratpoison은 C로 작성되었지만, 베츠의 StumpWM은 유사한 창 관리자를 커먼 리스프로 다시 구현한다.
"ratpoison"이라는 이름은 마우스를 사용하지 않고 응용 프로그램 창을 관리할 수 있도록 하는 주요 설계 목표를 반영한다. Ion과 같은 다른 타일링 창 관리자와 달리 ratpoison은 마우스("쥐")를 완전히 무시하고, 창 장식을 가능한 한 피한다. 기본 키 바인딩은 이맥스와 충돌하지 않도록 특별히 설계되었다.
ratpoison은 창 관리 제어를 위해 이맥스와 유사한 키 코드를 사용하며, 모든 창 상호 작용은 바로 가기를 통해 이루어진다. 각 창은 전체 프레임을 차지하며 겹칠 수 없다. 창은 가로 또는 세로로 분할할 수 있다. 여러 작업 공간과 세션 관리가 지원된다. 응용 프로그램 메뉴를 사용하여 프로그램으로 이동할 수 있다. 구성은 설정 파일을 통해 제어된다.
마크 필그림은 이를 "미니멀리스트"하고 "설정 가능"하다고 칭찬했다. 제프 코비는 2002년에 "번개처럼 빠르고 완벽하게 안정적"이라고 평가했다. 피터 시백은 "편의성과 성능은 인상적이지만, 학습 곡선은 많은 사용자를 위축시킨다"고 언급했다. 마찬가지로 브라이언 프로핏은 "이 창 관리자의 맨 페이지에 키 명령이 잘 설명되어 있으며, 무엇을 하든 먼저 이것들을 읽어야 한다. 키보드 명령은 어느 정도 사용 후 이해되지만, 초기 학습 곡선은 상당히 가파르다"고 관찰했다. 같은 맥락에서 브루스 바이필드는 (그리고 stumpwm) "문서를 읽기 전까지는 거의 사용할 수 없다"고 평가했다. MakeTechEasier는 2013년에 ratpoison에 대해 긍정적인 평가를 내렸지만, 가파른 학습 곡선을 지적했다. NetworkWorld의 브라이언 룬듀크는 부정적인 평가를 내렸고, 키 바인딩과 김프와 같은 다중 창 프로그램 작업의 어려움을 비판했다.
crDroid는 리니지OS를 기반으로 하는 안드로이드의 맞춤형 포크이다. 안드로이드 10부터 안드로이드 16까지 비공식 맞춤형 ROM을 제공했다.
crDroid 웹사이트는 지원되는 장치 목록과 각 장치의 최신 릴리스 날짜를 제공한다.
크리스티아누 마토스는 2012년 후반 삼성 갤럭시 S3용 crDroid 초기 버전을 개발했다.
2014년, 팀 안드로이드의 사드 칸은 자세한 기사에서 crDroid의 기능을 강조했다.
crDroid는 안정적인 릴리스와 사용자 친화적인 경험으로 인정을 받았다. 2015년 니라지 자스트, 2016년 라피아 샤이크, 2017년 매튜 디크하케의 기사 등이 주목할 만하다.
crDroid의 인기는 2019년 여러 장치에 안드로이드 10이 출시되면서 증가했으며, XDA 개발자의 아롤 라이트에 의해 인정받았다.
2022년, crDroid는 버전 8 (안드로이드 12)을 출시했다.
2023년, crDroid는 통합 커널 보조 슈퍼유저를 갖춘 일부 장치 빌드를 출시하기 시작했다.
현재 crDroid 버전 11은 안드로이드 15이다. 이와 함께 2024년 12월 보안 패치가 포함된 crDroid 10.11도 출시하고 있다.
소스 라인 오브 코드(Source lines of code, SLOC), 또는 라인 오브 코드(lines of code, LOC)는 프로그램 소스 코드 텍스트의 줄 수를 세어 컴퓨터 프로그램의 크기를 측정하는 데 사용되는 소프트웨어 메트릭이다. SLOC는 일반적으로 프로그램을 개발하는 데 필요한 노력의 양을 예측하고 소프트웨어가 생산된 후 프로그래밍 생산성 또는 유지보수성을 추정하는 데 사용된다.
여러 유용한 비교는 프로젝트 내 코드 라인의 크기 정도만을 포함한다. 10,000줄 프로젝트와 100,000줄 프로젝트를 비교하는 데 코드 라인을 사용하는 것이 20,000줄 프로젝트와 21,000줄 프로젝트를 비교하는 것보다 훨씬 유용하다. 코드 라인을 정확히 어떻게 측정할 것인지는 논란의 여지가 있지만, 크기 정도의 차이는 소프트웨어 복잡성 또는 공수의 명확한 지표가 될 수 있다.
SLOC 측정에는 물리적 SLOC (LOC)와 논리적 SLOC (LLOC)의 두 가지 주요 유형이 있다. 이 두 가지 측정의 구체적인 정의는 다르지만, 물리적 SLOC의 가장 일반적인 정의는 주석 줄을 제외한 프로그램 소스 코드 텍스트의 줄 수이다.
논리적 SLOC는 실행 가능한 "명령문"의 수를 측정하려고 시도하지만, 그 특정 정의는 특정 컴퓨터 언어에 묶여 있다(예를 들어, C와 유사한 프로그래밍 언어의 간단한 논리적 SLOC 측정은 명령문을 종료하는 세미콜론의 수이다). 물리적 SLOC를 측정하는 도구를 만드는 것이 훨씬 쉽고, 물리적 SLOC 정의는 설명하기 쉽다. 그러나 물리적 SLOC 측정은 논리적 SLOC보다 논리적으로 관련 없는 형식 지정 및 스타일 규칙에 더 민감하다. 그러나 SLOC 측정은 종종 정의를 제공하지 않고 언급되며, 논리적 SLOC는 물리적 SLOC와 크게 다를 수 있다.
SLOC를 결정할 때 발생하는 모호성의 예시로 다음 C 코드 스니펫을 고려해보자.
for (i = 0; i &lt; 100; i++) printf("hello"); /* How many lines of code is this? */
이 예시에서는 다음과 같다.
프로그래머와 코딩 표준에 따라 위의 "코드 라인"은 여러 개의 개별 라인으로 작성될 수 있다.
for (i = 0; i &lt; 100; i++)
심지어 "논리적" 및 "물리적" SLOC 값도 수많은 다양한 정의를 가질 수 있다. 로버트 E. 파크 (소프트웨어 공학 연구소 소속)와 다른 사람들은 프로젝트에서 사용되는 SLOC 측정을 신중하게 설명하고 정의할 수 있도록 SLOC 값을 정의하기 위한 프레임워크를 개발했다. 예를 들어, 대부분의 소프트웨어 시스템은 코드를 재사용하며, 측정을 보고할 때 어떤 (있다면) 재사용 코드를 포함할지 결정하는 것이 중요하다.
SLOC가 메트릭으로 도입될 당시, 포트란 및 어셈블리어와 같이 가장 일반적으로 사용되던 언어들은 라인 지향 언어였다. 이 언어들은 천공 카드가 프로그래밍을 위한 주요 데이터 입력 형태였던 시절에 개발되었다. 천공 카드 하나는 일반적으로 코드 한 줄을 나타냈다. 그것은 쉽게 셀 수 있는 개별적인 개체였다. 그것은 프로그래머의 가시적인 결과물이었기 때문에, 관리자들은 코드 줄을 프로그래머의 생산성 측정으로 세는 것이 합리적이라고 생각했으며, 심지어 "카드 이미지"라고 부르기도 했다. 오늘날, 가장 일반적으로 사용되는 컴퓨터 언어들은 형식 지정에 훨씬 더 많은 자유를 허용한다. 텍스트 줄은 더 이상 80 또는 96열로 제한되지 않으며, 텍스트 한 줄이 더 이상 반드시 코드 한 줄에 해당하지는 않는다.
SLOC 측정의 사용.
SLOC 측정은 다소 논란의 여지가 있으며, 특히 오용되는 방식에서 그렇다. 실험에 따르면 노력은 SLOC와 높은 상관관계가 있으며, 즉 SLOC 값이 큰 프로그램은 개발하는 데 더 많은 시간이 걸린다는 것이 반복적으로 확인되었다. 따라서 SLOC는 노력을 추정하는 데 효과적일 수 있다. 그러나 기능은 SLOC와 상관관계가 적다: 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있으므로, SLOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있다. SLOC를 생산성 측정으로 세는 것은 주의할 점이 있는데, 개발자는 몇 줄만 개발하고도 더 많은 줄을 생성하는 개발자보다 기능 측면에서 훨씬 더 생산적일 수 있기 때문이다(그리고 일반적으로 더 많은 노력을 들인다). 우수한 개발자는 여러 코드 모듈을 단일 모듈로 병합하여 시스템을 개선하지만, 코드를 제거했기 때문에 생산성이 음수로 나타날 수 있다. 또한, 미숙한 개발자는 종종 코드 중복에 의존하는데, 이는 버그 발생 가능성이 높고 유지 보수 비용이 많이 들기 때문에 매우 권장되지 않지만, SLOC를 높이는 결과를 초래한다.
SLOC 계산은 언어를 정규화하기 위해 조정 계수를 적용하지 않는 한, 다른 언어로 작성된 프로그램을 비교할 때 추가적인 정확성 문제를 나타낸다. 다양한 컴퓨터 언어는 간결성과 명확성 사이의 균형을 다르게 맞춘다. 극단적인 예로, 대부분의 어셈블리어는 APL에서 몇 글자로 동일한 작업을 수행하기 위해 수백 줄의 코드를 필요로 할 것이다. 다음 예시는 베이직, C, 그리고 (특히 장황한 것으로 알려진 언어인) 코볼로 작성된 "Hello world" 프로그램의 비교를 보여준다.
SLOC 메트릭을 비교하는 데 있어 또 다른 점점 흔해지는 문제는 자동 생성된 코드와 수작업으로 작성된 코드의 차이이다. 최신 소프트웨어 도구는 종종 몇 번의 마우스 클릭으로 엄청난 양의 코드를 자동 생성할 수 있다. 예를 들어, 그래픽 사용자 인터페이스 빌더는 아이콘을 작업 공간으로 드래그하는 것만으로 그래픽 제어 요소의 모든 소스 코드를 자동으로 생성한다. 이 코드를 생성하는 데 필요한 작업은 예를 들어 장치 드라이버를 작성하는 데 필요한 작업과 합리적으로 비교할 수 없다. 같은 맥락에서, 수작업으로 코딩된 사용자 지정 GUI 클래스는 간단한 장치 드라이버보다 훨씬 더 까다로울 수 있다. 따라서 이 메트릭의 단점이 드러난다.
널리 사용되는 배리 보임 등의 COCOMO 모델 시리즈, PRICE Systems True S 및 갈로라쓰의 SEER-SEM을 포함하여 SLOC를 입력 매개변수로 사용하는 여러 비용, 일정 및 노력 추정 모델이 있다. 이 모델들은 우수한 예측력을 보여주었지만, 입력된 추정치(특히 SLOC 추정치)만큼만 좋다. 많은 이들은 기능성 측정으로 SLOC 대신 기능 점수 사용을 주장했지만, 기능 점수가 SLOC와 높은 상관관계가 있고 (자동으로 측정될 수 없기 때문에) 이는 보편적으로 받아들여지는 견해가 아니다.
빈센트 마라이아(Vincent Maraia)에 따르면, 마이크로소프트의 윈도우 NT 제품군의 다양한 운영 체제의 SLOC 값은 다음과 같다.
데이비드 A. 휠러(David A. Wheeler)는 리눅스 운영체제의 레드햇 배포판을 연구했으며, 레드햇 리눅스 버전 7.1 (2001년 4월 출시)이 3천만 줄 이상의 물리적 SLOC를 포함하고 있다고 보고했다. 그는 또한 이 배포판이 기존의 독점적인 방식으로 개발되었다면 약 8천 인년의 개발 노력이 필요했을 것이며 10억 달러 이상(2000년 미국 달러 기준)의 비용이 들었을 것이라고 추정했다.
유사한 연구가 나중에 데비안 GNU/리눅스 버전 2.2("포테이토"라고도 함)에 대해 수행되었다. 이 운영 체제는 2000년 8월에 원래 출시되었다. 이 연구는 데비안 GNU/리눅스 2.2가 5천5백만 줄 이상의 SLOC를 포함하고 있으며, 기존의 독점적인 방식으로 개발되었다면 14,005 인년이 필요하고 개발 비용으로 미화 19억 달러가 들었을 것이라고 밝혔다. 나중에 사용된 도구의 실행 결과에 따르면 데비안의 다음 릴리스는 1억 4백만 SLOC를 가졌고, , 최신 릴리스는 2억 1천 3백만 SLOC 이상을 포함할 예정이다.
PBS 다큐멘터리 너드들의 승리에서 마이크로소프트의 임원인 스티브 발머는 코드 라인 수를 세는 관행을 비판했다.
IBM에는 소프트웨어에 대한 종교가 있는데, K-LOC를 세야 한다고 말한다. K-LOC는 천 줄의 코드다. 프로젝트 규모는? 아, 대략 10K-LOC 프로젝트야. 이건 20K-LOC짜리야. 이건 50K-LOC짜리야. IBM은 우리가 어떻게 돈을 벌었는지, 그들이 얼마나 했는지에 대한 종교를 만들고 싶어 했다. 우리가 OS/2로 얼마나 많은 돈을 벌었는지, 그들이 얼마나 했는지. K-LOC를 몇 개 만들었냐고? 우리는 계속해서 그들을 설득하려고 했다. "이봐, 만약 개발자가 좋은 아이디어를 가지고 20K-LOC 대신 4K-LOC로 뭔가를 해낼 수 있다면, 우리가 돈을 덜 벌어야 할까?" 그는 더 작고 빠른 것을 만들었는데, K-LOC는 더 적었다. K-LOC, K-LOC, 그게 방법론이다. 에휴! 어쨌든, 그 생각만 하면 항상 등골이 오싹해진다.
컴퓨터 역사 박물관에 따르면 애플 개발자 빌 앳킨슨은 1982년에 이 관행에 문제점을 발견했다.
1982년 Lisa 팀이 소프트웨어를 완성하기 위해 노력하고 있을 때, 프로젝트 관리자들은 프로그래머들에게 매주 작성한 코드 라인 수를 보고하는 양식을 제출하도록 요구하기 시작했다. 빌 앳킨슨은 그것이 어리석다고 생각했다. QuickDraw의 영역 계산 루틴을 6배 더 빠르게 만들고 2000줄 더 짧게 만든 주에 그는 양식에 "-2000"이라고 기입했다. 몇 주 후에 관리자들은 그에게 양식을 작성하라고 요구하지 않았고, 그는 기꺼이 따랐다.
SLOC는 다음 뜻이 있다.
해상 교통로(sea lines of communication, 약칭 SLOC)는 항구 간의 주요 해운 경로를 나타내는 용어로, 무역, 물류 및 해군에 사용된다. 일반적으로 SLOC가 개방되도록 보장하기 위한 해군 작전이나 전쟁 시 이를 폐쇄하기 위해 사용된다.
지정학에서 SLOC의 중요성은 1942년에 출판된 니콜라스 J. 스피크먼의 '미국의 세계 정치 전략'에서 설명되었다.
미국 독립 전쟁과 나폴레옹 전쟁에서 SLOC는 대부분 영국 해군의 통제하에 있었다. 영국이 혁명 중 통제권을 잃었을 때, 그 결과는 요크타운 전투와 가장 큰 군대의 함락, 그리고 궁극적으로는 전쟁이었다. 나폴레옹 시대 내내 전쟁을 유지하면서 영국은 나폴레옹과 관련된 모든 국가를 금수 조치하고 봉쇄하여 프랑스 국민이 나폴레옹에게 환멸을 느끼게 하는 데 일조한 막대한 경제적 어려움과 혼란을 초래했다.
제1차 세계 대전과 제2차 세계 대전에서 영국과 독일은 상호 봉쇄를 선언했고 전쟁해군은 잠수함을 사용하여 북아메리카에서 브리튼 제도로 이어지는 SLOC를 폐쇄하려고 시도했다. 두 경우 모두 연합군은 해상 교통로를 개방하는 데 성공했다. 두 경우 모두 독일은 독일에 대한 영국의 해군 봉쇄를 물리치지 못했다. 제2차 세계 대전의 미국 해군은 일본으로 가는 SLOC를 성공적으로 폐쇄하여 자원 빈곤국인 일본을 질식시켰다.
만약 냉전이 열전으로 변했다면, 유럽은 북아메리카로부터 재보급 및 증원을 필요로 했을 것이다. 소련 해군은 유럽에서 지상 공격을 지원하기 위해 대서양 SLOC를 잠재적으로 위협하고 경쟁할 수 있었을 것이다.
붉은줄지렁이()는 줄지렁이와 가까운 관계에 있는 낚시지렁이과의 환형동물이다. 줄지렁이와 마찬가지로 표생성이며, 따라서 광물성 토양보다는 퇴비나 낙엽층에 서식하는 것을 선호한다.
붉은줄지렁이는 색깔이 더 어둡고 특징적인 줄무늬가 덜 뚜렷해 줄지렁이와 구별할 수 있다. 분자 분석(단백질 동형 효소의 전기영동 기반)을 통해 1980년대 중반에 별개의 종으로 완전히 동정되었음에도 불구하고, 붉은줄지렁이는 여전히 줄지렁이와 혼동되거나 오동정되는 경우가 많다. 붉은줄지렁이 배아의 근육은 적어도 두 개의 뚜렷한 근육군으로 나타나고 처음부터 복부 정중선을 가로질러 배아의 측면으로 뻗어 있다. 두 종은 필요성, 일반적인 번식 성능 및 생활환 측면에서 형태상 매우 닮아있지만, 붉은줄지렁이는 더 진화된 기질 특성으로 인해 줄지렁이보다 더 빠른 성장률과 알집 생산율을 보인다.
아스트라 리눅스(Astra Linux)는 마이크로소프트 윈도우를 대체하기 위해 러시아 연방에서 널리 배포되고 있는 러시아의 리눅스 기반 운영체제(OS)이다. 초기에는 러시아군, 기타 군대 및 정보기관의 요구를 충족시키기 위해 만들어지고 개발되었다. 강제적 접근 제어 기능을 통해 러시아 기밀정보 등급에서 "일급비밀" 수준의 데이터 보호를 제공한다. 러시아 국방부, 러시아 연방 기술 수출 통제청 및 러시아 연방보안국으로부터 공식적으로 인증을 받았다.
2010년대에 러시아 당국과 산업계가 서방 제품에 대한 의존도를 낮추려고 노력하면서("수입 대체 산업화") 군대와 경찰 외에도 교육, 의료 및 기타 국영 기관뿐만 아니라 러시아 철도, 가스프롬, 로사톰과 같은 거대 산업체에도 공급되고 있다. 아스트라 리눅스의 서버 버전은 화웨이 장비와 함께 작동하도록 인증을 받았다.
운영체제의 개발자는 과학/제조 기업 Rusbitech으로, 연방 당국 및 예산 기관에 자유 소프트웨어 사용을 의무화하는 2010년 10월 17일 러시아 정부 법령 No. 2299-р에 따라 솔루션을 적용하고 있다.
운영체제는 두 가지 에디션으로 제공된다: 주요 에디션은 "Special Edition"이라 불리고 다른 하나는 "Common Edition"이라 불린다.
둘 사이의 주요 차이점은 전자는 유료이고 후자는 무료라는 점이다. 전자는 x86-64 아키텍처, ARM 아키텍처 및 옐브루스 아키텍처에서 사용할 수 있는 반면, 후자는 x86-64 아키텍처에서만 사용할 수 있다. 전자는 보안 인증을 받았고 3단계 OS 보안 수준(러시아 도시의 이름을 따서 명명되었으며, 가장 낮은 수준부터 가장 높은 수준까지 오룔, 보로네시, 스몰렌스크이다)을 제공하는 반면, 후자는 보안 인증이 없으며 가장 낮은 수준의 OS 보안(오룔)만 제공한다.
Rusbitech은 또한 PCI 버스를 갖춘 "소프트웨어/하드웨어 신뢰 부팅 제어 모듈" MAKSIM-M1("М643М1")을 제조한다. 이는 무단 접근을 방지하고 다른 강화된 디지털 보안 기능을 제공한다. 이 모듈은 아스트라 리눅스 외에도 리눅스 커널 2.6.x부터 5.x.x까지의 OS와 여러 마이크로소프트 윈도우 OS를 지원한다.
아스트라 리눅스 라이선스는 러시아 및 국제 법률을 준수하며 "GPL 라이선스의 정신과 요구에 모순되지 않는다"고 선언되었다. 이 시스템은 .deb 패키지를 사용한다.
아스트라 리눅스는 인정받는 데비안 파생 배포판이다. Rusbitech은 리눅스 재단과 파트너십 관계를 맺고 있다. 이 회사는 한때 도큐먼트 재단의 자문 위원회 일원이었으나, 2022년 러시아의 우크라이나 침공으로 인해 2022년 2월 26일 정지되었다.
스페셜 에디션 버전(유료)은 많은 러시아 국영 관련 기관에서 사용된다. 특히 러시아 국방 통제 센터에서 사용된다.
크림 공화국의 많은 국영 기관에서 아스트라 리눅스의 대규모 사용을 배치하려는 논의가 진행 중이다. 러시아-우크라이나 전쟁 중 국제 제재로 인해 다른 인기 있는 운영체제의 합법적 사용은 의문시된다.
또한 Rusbitech과 화웨이의 협력 계획도 있었다.
2018년 1월, 아스트라 리눅스가 모든 러시아군 컴퓨터에 배포되고 마이크로소프트 윈도우는 중단될 것이라고 발표되었다.
2018년 2월, Rusbitech은 아스트라 리눅스를 러시아산 옐브루스 마이크로프로세서에 이식했다고 발표했다.
2019년 2월, 아스트라 리눅스가 중국의 톈완 원자력 발전소에 구현될 것이라고 발표되었다.
2019년부터 "초고보호" 태블릿 컴퓨터인 MIG 브랜드가 아스트라 리눅스와 함께 판매되고 있으며, 스마트폰도 출시될 예정이다.
2019년에는 가스프롬 국영 가스/석유 기업이 아스트라 리눅스 구현을 발표했으며, 2020년에는 원자력 기업 로사톰이, 2021년 초에는 러시아 철도가 이를 시행할 것이라고 보도되었다.
2020년, 아스트라 리눅스는 100만 개 이상의 라이선스를 판매하고 20억 루블의 매출을 올렸다.
2021년, 여러 러시아 원자력 발전소와 로사톰의 자회사들이 아스트라 리눅스로 전환할 계획이며, 총 15,000명의 사용자가 예상된다.
2022년 7월, 마이크로소프트가 러시아 시장에서 철수하기로 결정한 후, 아스트라 리눅스는 공개 상장을 모스크바 증권거래소에서 계획하고 있다고 발표했지만, 당시 상장 예정 날짜는 밝히지 않았다.
x.7 업데이트부터 아스트라 리눅스 스페셜 에디션 운영 체제는 중첩된 패키지 저장소 구조를 사용하며, 이 구조는 메인 저장소, 기본 저장소, 확장 저장소로 구성된다. 메인 x.7 저장소는 일반적으로 버전 1.6과 동일하며, 기본 저장소는 모든 핵심 패키지와 개발 도구 관련 패키지를 포함한다.
확장 저장소는 주 저장소와 기본 저장소에 없는 소프트웨어 패키지 버전을 보관한다. 이러한 소프트웨어는 아스트라 리눅스 환경 내에서 작동하며, CSS를 사용한 보안 기능을 통합하기 위해 변경되지 않고, 기본 및 주 저장소의 패키지와 호환되지 않을 수 있으며, 인증 테스트를 거치지 않는다.
확장 저장소는 기본 및 핵심 저장소보다 더 많은 기능을 제공하며, 확장 저장소 패키지는 기본 패키지를 수정할 수 있지만 핵심 패키지는 수정할 수 없다.
또한, 확장 저장소는 기본 및 확장 저장소의 패키지와 호환되지 않을 수 있는 최신 버전의 패키지를 제공하는 백포트 구성 요소와 타사 소프트웨어와의 최대 호환성을 보장하는 패키지를 제공하는 "Astra-ce 구성 요소"를 포함한다.
확장 저장소를 사용하면 사용자는 다른 리눅스 시스템용으로 설계된 소프트웨어를 설치하고 실행하며, 자신의 소프트웨어를 개발하고, 아스트라 리눅스를 다양한 하드웨어 플랫폼에 적용할 수 있다.
확장 저장소 소프트웨어 패키지의 주요 범주는 기본 저장소에 포함되지 않은 패키지, 기본 저장소를 업데이트하는 패키지(즉, 기본 저장소 패키지의 최신 버전 – 호환되지 않으면 백포트 구성 요소에 통합된다), 그리고 주 저장소의 패키지를 대체하는 패키지이다. 후자는 Astra-ce 구성 요소에 통합되어 있으며, 여기에는 PostgreSQL DBMS, Exim (Exim4) 이메일 서비스, MariaDB DBMS 패키지, 자바 OpenJDK 도구, 그리고 리브레오피스 오피스 스위트가 포함된다.
레드햇 엔터프라이즈 리눅스 파생판(Red Hat Enterprise Linux derivatives)은 레드햇 엔터프라이즈 리눅스(RHEL) 리눅스 배포판을 기반으로 하는 리눅스 배포판이다.
레드햇 리눅스는 유료 지원 버전이 있는 동시에 무료 다운로드 버전도 제공되었기 때문에 매우 인기 있는 리눅스 배포판이었다. 유료 옵션과 무료 옵션의 유일한 차이점은 지원 여부였기 때문에 많은 사람들이 무료 버전을 사용하기로 선택했다.
2003년 레드햇은 레드햇 리눅스 제품을 유료 고객을 위한 레드햇 엔터프라이즈 리눅스로 변경하기로 결정했다.
페도라라고 불리는 커뮤니티 주도의 레드햇 기반 리눅스 배포판은 무료로 제공되었다.
페도라는 자체 베타 주기를 가지며, 가끔 레드햇 직원도 포함되는 기여자들에 의해 일부 문제가 수정된다. 그러나 빠르고 보수적이지 않은 릴리스 주기는 일부 사용자에게는 적합하지 않을 수 있음을 의미한다.
오늘날 페도라는 CentOS 스트림의 주요 상위 개발 브랜치 역할을 하며, 이는 다시 레드햇 엔터프라이즈 리눅스로 이어진다.
레드햇 엔터프라이즈 리눅스 파생판은 일반적으로 RHEL의 다양한 버전에 포함된 합집합을 포함한다. 버전 번호는 일반적으로 RHEL에 포함된 번호와 동일하다. 따라서 무료 버전은 유료 버전과 이진 호환성을 유지하며, 이는 RHEL용으로 제작된 소프트웨어가 일반적으로 무료 버전에서도 실행됨을 의미한다. 배포판에는 상대적으로 적은 변경만 필요하다.
레드햇의 배포판이 파생된 GNU 일반 공중 사용 허가서는 무료 재배포를 명시적으로 장려한다. 그러나 레드햇 상표의 오용을 피하기 위해, 상표로 보호되는 원본 배포판의 자료는 재배포에서 제거되어야 한다.
배포판(예: CentOS)이 레드햇에 대한 언급을 충분히 제거하지 않았다고 판단될 경우, 레드햇의 법률 고문으로부터 경고를 받았다. CentOS는 웹사이트와 배포판에서 레드햇의 주장된 상표에 대한 모든 언급을 제거하라는 통지를 받았다.
주목할 만한 레드햇 엔터프라이즈 리눅스 파생판.
RHEL 기반의 어플라이언스 지향 파생판:
생산이 중단되거나 오래된 배포판:
KaOS는 최신 버전의 KDE 데스크톱 환경을 중심으로 구축된 아치 기반 리눅스 배포판이다. 여기에는 리브레오피스와 Qt 툴킷을 기반으로 하는 기타 인기 소프트웨어 애플리케이션이 포함된다.
KaOS의 첫 번째 버전은 2013년에 "KdeOS"로 출시되었다. 배포판 이름과 데스크톱 환경 KDE 간의 혼동을 피하기 위해 2013년 9월에 이름이 "KaOS"로 변경되었다.
KaOS는 ISO 이미지를 통해 배포되며, 64비트 X86 프로세서만 지원한다.
KaOS는 매우 구체적인 초점을 가지고 처음부터 구축된 데스크톱 롤링 릴리스이다. 하나의 데스크톱 환경(KDE 플라스마 6), 하나의 툴킷(Qt), 하나의 아키텍처(X86 64)에 초점을 맞추고 가장 적합한 도구와 애플리케이션을 평가하고 선택하는 데 중점을 둔다.
기본 애플리케이션은 다음과 같다.
Phoronix는 2016년에 "전반적으로, 틈새 배포판임에도 불구하고 상당히 만족스러웠다. KaOS는 설치하기 쉬웠고 최신 KDE 플라스마 5 스택에서 빠르게 실행되었다. 전반적으로 KaOS와 함께 즐겁고 쾌적한 몇 시간을 보냈다"라고 썼다.
FossMint는 2017년에 KaOS가 "현대적이고 오픈 소스이며 아름답게 디자인된 QT 및 KDE 중심 리눅스 배포판이다. KDE 플라스마를 기본 데스크톱 환경으로 사용하는 롤링 릴리스이며, 패키지 관리자로 Pacman을 사용하고 GitHub에 3그룹 구조 리포지토리를 가지고 있다"고 밝혔다. 또한 "롤링 릴리스라는 사실은 우분투와 같이 다른 '주요 버전'을 새로 설치할지 여부를 고려해야 하는 경우와 달리 일단 버전이 설치되면 향후 업데이트에 대해 걱정할 필요가 없다는 것을 의미한다"고 덧붙였다.
Hectic Geek은 2014년에 KaOS를 검토했으며, 이 배포판이 그리 빠르지는 않지만 필요한 모든 애플리케이션을 포함하고 있다고 썼다.
디스트로워치 위클리의 제시 스미스는 KaOS 2014.04에 대한 리뷰를 썼다. 스미스는 KaOS의 기능이 잘 작동한다고 말했다.
로버트 라이코프는 디스트로워치 위클리에 KaOS 2017.09를 리뷰하며 "KaOS는 뭔가 다르게 보이려고 너무 애쓰는 것 같다"고 말했다.
지디넷은 KaOS 2014.06에 대한 실습 리뷰를 썼다.
Dedoimedo는 KaOS 2014.12를 리뷰했다.
Linux.com의 잭 월런은 2016년에 KaOS에 대한 자신의 의견을 밝혔고, 이 배포판이 아름답다고 말했다.
Quassel IRC 또는 간단히 Quassel은 2008년에 소개된 그래픽 분산 IRC 클라이언트이다. GNU 및 유닉스 계열 운영체제, macOS, 마이크로소프트 윈도우용으로 GNU 일반 공중 사용 허가서 버전 2 및 버전 3으로 출시되었다. 크로스 플랫폼 특성 덕분에 OS/2 Warp로도 이식되었다. 쿠분투 9.04(재운티 재칼로프) 출시 이후 Quassel은 쿠분투의 기본 IRC 클라이언트이다. Quassel은 Qt 애플리케이션 프레임워크를 사용한다.
Quassel의 주요 기능은 사용자의 서버에 채팅 기록을 저장하고, 사용자의 컴퓨터가 오프라인이었을 때의 채팅 기록을 포함하여 사용자에게 제공하는 것이다.
Quassel은 클라이언트 서버 모델을 기반으로 한다. 핵심 애플리케이션은 LAN 또는 인터넷을 사용하여 하나 이상의 클라이언트에 연결하고 다양한 IRC 서버에도 연결한다. 클라이언트는 IRC 서버와 직접 통신하지 않고, 핵심 애플리케이션을 통해 통신한다. 이런 방식으로, 클라이언트가 사용하지 않더라도 핵심 애플리케이션에 의해 IRC 네트워크 연결이 유지된다. 애플리케이션의 모노리스 버전도 지원되는데, 이는 핵심과 클라이언트 간에 분리 없이 일반 IRC 클라이언트처럼 작동한다. 안드로이드(Quasseldroid) 및 iOS(iQuassel) 클라이언트도 사용할 수 있다.
이 시스템은 Irssi, GNU Screen과 함께하는 WeeChat, 그리고 Smuxi가 사용하는 것과 유사하다.
Quassel은 여러 IRC 서버에 동시에 연결할 수 있게 한다. 다른 아이덴티티를 생성하여 코어가 연결하는 하나 이상의 서버에서 사용할 수 있다. 각 아이덴티티에는 기본 닉네임, 대체 닉네임, 부재중 메시지 등이 포함된다. 각 아이덴티티는 하나 이상의 서버에 할당될 수 있다.
Quassel은 채팅 기록을 PostgreSQL 또는 SQLite 데이터베이스에 저장한다. 채팅 창을 위로 스크롤하면 이전 채팅 부분이 저장된 로그에서 자동으로 로드된다. 이런 방식으로 과거 대화 로그를 원활하게 볼 수 있다.
별칭, 즉 명령 단축키도 사용할 수 있다. 이를 통해 사용자는 많은 매개변수가 있는 긴 명령에 대한 별칭을 만들 수 있다. 클라이언트와 코어 간의 연결은 SSL(Secure Sockets Layer)을 사용하여 암호화할 수 있으며, 프록시가 지원된다.
2009년 탐스 하드웨어의 대형 IRC 클라이언트 종합 평가에서 애덤 오베라는 Quassel을 "풍부한 기능"과 "수많은 옵션"을 갖추고 있으며, "새로운 사용자조차도 서버 사전 설정 및 채널 목록을 위한 GUI 도구를 사용하여 서버에 연결하고 채널을 찾는 데 아무런 문제가 없을 것"이라고 설명했다.
mpv는 엠플레이어, mplayer2 및 FFmpeg를 기반으로 하는 자유-오픈 소스 미디어 플레이어이다. 유닉스 계열 운영체제(리눅스, BSD 기반, macOS) 및 마이크로소프트 윈도우를 포함한 여러 운영체제에서 실행되며, mpv-android라는 안드로이드 포트도 있다. 크로스 플랫폼이며 ARM, MIPS, PowerPC, RISC-V, s390x, X86/IA-32, X86-64 및 기타 타사에서 지원되는 일부 플랫폼에서 실행된다.
mpv는 2012년에 빈센트 랑(wm4로도 알려짐)이 2010년에 엠플레이어에서 포크된 mplayer2에서 포크했다. 포크의 동기는 유지보수 불가능한 코드를 제거하고 매우 오래된 시스템에 대한 지원을 중단하여 개발자 활동을 장려하기 위함이었다. 그 결과 프로젝트는 많은 기여를 받았다.
2015년 6월부터 프로젝트의 소스 코드는 mpv를 더 많은 애플리케이션에서 라이브러리로 사용할 수 있도록 GNU 일반 공중 사용 허가서 버전 2 이상(GPLv2+)에서 GNU 약소 일반 공중 사용 허가서 버전 2.1 이상(LGPLv2.1+)으로 재라이선싱되고 있다.
엠플레이어의 변화.
mpv는 엠플레이어에서 포크된 이후 몇 가지 주목할 만한 변화가 있었다. 첫눈에 가장 분명한 변화는 기본적인 마우스 상호작용을 제공하는 최소한의 온스크린 컨트롤러(OSC)가 추가되었다는 점이다. 이는 새로운 사용자가 상호작용하기 쉽도록 하고 정확하고 직접적인 탐색을 가능하게 하기 위함이었다.
인터페이스 및 그래픽 프론트엔드.
원래 엠플레이어와 마찬가지로 mpv는 여전히 주로 명령줄 애플리케이션이다. 그러나 제한된 마우스 제어를 허용하는 기본적인 온스크린 컨트롤러(OSC)도 있다. 이 OSC는 아직 완전한 기능을 갖춘 GUI는 아니며, Qt, GTK 또는 다른 툴킷용 GUI 위젯을 사용하여 더 완벽한 UI를 제공하는 여러 그래픽 프론트엔드가 있다.
다음은 mpv(libmpv 또는 mpv의 명령줄 버전 기반)의 일부 오픈 소스 프론트엔드이며, mpv보다 더 많은 기능과 더 사용자 친화적인 인터페이스 및 다양한 운영체제 또는 데스크톱 환경과의 더 나은 통합을 제공하려고 노력한다.
KDE 플라스마 6(KDE Plasma 6)은 KDE 플라스마 데스크톱 환경의 여섯 번째이자 최신 세대이다. KDE 플라스마 5의 후속작이며 2024년 2월 28일에 처음 출시되었다.
KDE 플라스마 6은 KDE 플라스마 5와 크게 다르지 않고 일련의 개선 사항들을 중심으로 설계되었다. KDE 플라스마 6은 Qt 6, KDE 프레임워크 6 및 KDE 기어 24.02를 사용하여 빌드되었다. 또한, 웨이랜드 프로토콜 지원이 기본 그래픽 세션으로 주류화되었으며, X11 지원은 보조적으로 사용된다. 새로운 사운드 테마인 오션이 도입되어 옥시즌의 사운드 테마를 기본으로 대체한다. 웨이랜드의 플라스마 6은 HDR(High Dynamic Range) 및 색맹 보정 필터에 대한 부분적인 지원을 제공한다. 디스커버 앱과 설정도 개선되었으며 3D 큐브 데스크톱 효과가 다시 추가되었다.
최신 플라스마 5 릴리스와 비교하여, 6세대에서는 다음과 같은 새로운 기능이 추가되었다.
플라스마 6의 첫 번째 안정 버전은 2024년 2월 28일에 출시되었다.
기준으로, 새로운 기능이 포함된 주요 버전은 4개월마다 출시되며, 연간 3번의 업데이트가 제공된다. 그러나 2023년부터 KDE 커뮤니티는 플라스마를 패키지하는 주요 리눅스 배포판(우분투, 오픈수세 립, 페도라)의 릴리스와 시기를 맞출 수 있다면 6개월마다 업데이트되는 반기 일정으로 전환하는 것을 선호한다고 밝혔다.
각 릴리스는 최대 6개의 버그 수정 패치 릴리스를 받는다. 다음 주요 릴리스가 출시되는 즉시 릴리스는 버그 수정을 중단한다. 플라스마 6의 장기 지원 버전을 제공할 계획은 없다.
사교좌표(skew coordinates)는 직교좌표계에서처럼 직교 좌표가 아닌 곡선 좌표계를 일컫는다.