User:ScotXW

Hardware

• Pascal: 64 single-precision shader cores AND 32 double-precision units per SM (streaming multiprocessor) in a GP100; GP100 SM is partitioned into two processing blocks, each having 32 single-precision CUDA Cores, an instruction buffer, a warp scheduler, and two dispatch units. providing a 2:1 ratio of single- to double-precision throughput. Compared to the 3:1 ratio in Kepler GK110 GPUs, this allows Tesla P100 to process FP64 workloads more efficiently. Using FP16 computation improves performance up to 2x compared to FP32 arithmetic, and similarly FP16 data transfers take less time than FP32 or FP64 transfers. The GP100 SM ISA provides new arithmetic operations that can perform two FP16 operations at once on a single-precision CUDA Core, and 32-bit GP100 registers can store two FP16 values. Nvidia Blog

• OpenGL is a state machine. A single monolithic set of states that control all aspects of the rendering (Bildsynthese) process. The API is used to put the OpenGL driver into various modes. The modes remain in effect until they get changed again. Current color, vertex and buffers array, viewport, depth ranges, rasterization, culling, multi sampling texture modes are set with glEnable and glDisable.
• In Vulkan there is no huge state machine. Instead Pipelines State Objects (PSOs) are constructed. PSOs are containers that store all the information required for the current rendering. A PSO represents the processing paths that vertices go through on their way to being rendered. PSOs define the stages like Vertex, Tessellation Control, Tessellation Evaluation, Geometry and Fragment and the compiled shaders that are to be used for those stages. PSOs additionally contain information about color blending, the viewport, i.e. the area and the render target to render to, multisampling, i.e. the number of samples to calculate at each pixel on the render target, etc.
  • PSO can also hold information about the dynamic state, i.e. properties of the PSO that are dynamic, i.e. they can be changed independently.
  • Once build and compiled PSOs can be cached or serialized from one execution to another; far more encompassing then OpenGL pre-compiled shaders
• In OpenGL you issue a list of GL commands to do rendering, but there is no easy way to store these commands for re-use!
• Vulkan uses Command Buffers. Commands are recorded into a Command Buffer and subsequently submitted to a device queue for execution on the GPU; Command Buffers can be re-used and re-recorded. Recorded commands include such that bind pipelines and descriptor sets, such that draw, such that modify dynamic state, etc.
  • Command Buffers are allocated from Command Pools, which allocate memory for the Command Buffer as it is being recorded. Recording Command Buffers has a big impact on performance: in case they are created during rendering, it is to be considered to use threads to build the command buffers.
• Shaders access resources such as buffers and images:
  • In OpenGL use glGet_bla to figure out where to set resources like e.g. textures, that some shader will access
  • In Vulkan shader resources are known as resource descriptors, and there are about 12 types supported by Vulkan: Sampler, Uniform Buffer, Storage Buffer, etc.
• Threading requires synchronization between Command Buffers when they get build. With Vulkan there is also concurrency between the driver and the device and between queues. Vulkan has synchronization primitives:
  • Fences: used to determine the completion of submissions made to queues; after submitting wait on the fence to become available and continue on
  • Semaphores: used to coordinate operations between queues, e.g. marshal ownership of shared data
  • Events: used to gauge progress through a sequence of commands
  • Pipeline, memory and buffer barriers:

• Category:Video compression and decompression ASIC

Desktop GPUs

Main articles: GeForce 1000 Series, Pascal (microarchitecture), and AMD Radeon 400 series

• AMD: 7 chips in 28nm since 2012:
  • 2016: 2 chips in 14nm: Polaris 10, Polaris 11
• Nvidia: 9 chips in 28nm since 2012: 5 Kepler (GK107, GK208, GK106, GK104, GK110); 4 Maxwell (GM107; GM206, GM204, GM200), +1 chip dedicated to computation: The GK210 __cannot__ be used as GPU it is found only on "K80 GPU Accelerator" PCIe-cards
  • 2016: 4 chips in 16nm since 2016: GP107, GP104, GP106, GP102, +1 chip dedicated to computation: The GP100 __cannot__ be used as GPU!

A part of the price of a graphics card is the cost of the GPU chip. The cost of the GPU chip could be split into design and manufacturing. The cost for manufacturing could be split into wafer and microfabrication. The bigger the share of the cost for the production of the wafer, the bigger the influence of the GPU's die surface on the graphics card end price, the more elegant to produce a relatively smaller chip that can run a high clock speeds. Nvidia has had rather a tendency towards bigger chips, yet their Tesla 1.0 design clocked the shader ALUs at 1.5 GHz, and now again, their Pascal-based GPUs are clocked at 1.5 GHz.

The GP106 (4400 Mio, 200mm²) competes with both the Polaris 10 (5700Mio,232mm²) and the Polaris 11 (3000Mio,123mm²) chips, meaning the GP104 (7200Mio, 297mm²) as well as the GP102 (12,000Mio, 471mm²) have no 14/16nm competition from AMD.

Pascal Maximum Digital Resolution: 7680x4320@60Hz (7680x4320 at 60Hz RGB 8-bit with dual DisplayPort connectors or 7680x4320 at 60Hz YUV420 8-bit with one DisplayPort 1.3 connector.) Maximum Digital Resolution: DP 1.4, HDMI 2.0b, Dual Link-DVI

More information Graphics card, Launch ...

Graphics card	Launch	Release Price (US-$)	TDP (watts)	API support (version)				GPU chip							Memory Configuration					Theoretical (=calculated) values					Real-life benchmarks4
				Direct3D	OpenGL	OpenCL	Vulkan	Arch	Name	Transistors (Million)	Die size (mm²)	Core config1	Clock rate		Amount (GiB)	Bus width (bit)	DRAM type	Memory (MT/s)	Bandwidth (GB/s)	Processing Power (GFLOPS)2			Fillrate3		Game x			Game y			Game z
													Base (MHz)	Boost (MHz)						Half Precision	Single Precision	Double Precision	Texture (GT/s)	Pixel (GP/s)	Frame rate	FPS/Price	FPS/Power	Frame rate	FPS/Price	FPS/Power	Frame rate	FPS/Price	FPS/Power
8800 GTS 512	2007-12-11	$380	135W	10.0	3.3	1.1	no	Telsa 1.0	G92-400 (65nm)	754	324	128:64:16	650 1625	—N/a	0.5	256	GDDR3	1940	62.1	—N/a	416	—N/a	41.6	10.4
GTX 285	2009-01-15	$	204W	10.1				Telsa 2.0	GT200 (55nm)	1400	470	240:80:32	648 1476	—N/a	1	512		2484	159.0	—N/a	708.5	—N/a	51.84	20.7
GTX 480	2010-03-26	$500	250W	12.0 (11_0)	4.6	1.2		Fermi	GF100 (40nm)	3000	529	480:60:48	700 1401	—N/a	1.5	384	GDDR5	3696	177.4	?	1344.96	168.12	42	33.6
GTX 650	2012-09-13	$110	64W				1.1	Kepler	GK107	1300	118	384:32:16	1058	1058	1 2	128		5000	80	?	33.86	812.54	33.8	16.9
GTX 650 Ti	2012-10-09	$150	110W						GK106	2540	221	768:64:16	928	928	1 2			5400	86.4	?	1425.41	59.39	59.4	14.8
GTX 660	2012-09-13	$230	140W									960:80:24	980	980	2	192		6008	144.2	?	1881.6	78.40	78.4	23.5
GTX 680	2012-03-22	$500	195W						GK104	3540	294	1536:128:32	1006	1058	2 4	256		6008	192.0	?	2258	94.1	94.1	31.4
GTX 770	2013-05-30	$400	230W										1046	1085				7010	224	?	3213	134	134	33.5
GTX 780	2013-05-23	$650	250W						GK110	7080	561	2304:192:48	863	900	3	384		6008	288	?	3977	166	166	41.4
GTX 780 Ti	2013-11-07	$700										2880:240:48	876	928	3			7000	336	?	5046	210	210	42.0
GTX 950	2015-08-20	$160	90W	12.0 (12_1)				Maxwell 2.0	GM206	2940	227	768:48:32	1024	1188	2 4	128		6610	106	?	1572	49.1	49.2	32.7
GTX 960	2015-01-22	$200	120W									1024:64:32	1127	1178	2 4			7010	112	?	2308	72.1	72.1	39.3
GTX 970	2014-09-18	$330	145W						GM204	5200	398	1664:104:56	1050	1178	3.5+0.5	196+28			192+32	?	3494	109	109.2	54.6
GTX 980		$550	165W									2048:128:64	1126	1216	4	256			224	?	4612	144	144	72.1
GTX 980 Ti	2015-06-02	$649	250W						GM200	8000	601	2816:176:96	1000	1076	6	384			336	?	5632	1/32	176	96
GTX Titan X	2015-03-17	$1000										3072:192:96		1089	12					192	?	6144	192
Tesla P100	2016-06-20	???	300W					Pascal	GP100	12,000	471	3840:0:0	1354	1455	12 24	1024	HBM1			?	?	?
GT 1030	2017-05-17	$80	305W	12.0 (12_1)	4.5		1.0		GP108	1800	70	384:24:16	1227	1468	2	64	GDDR5	6000	48	15	942	29	29.4	19.6
GTX 1050	2016-10-25	$110	75W						GP107	3300	132	640:40:32	1354	1455	2	128		7000	112	?	1800	?	84.2	42.1
GTX 1050 Ti		$140										768:64:32	1290	1392	4					?	2100	?	84.2	42.1
GTX 1060 3	2016-09-18	$200	120W						GP106	4400	200	1152:72:48	1506	1708	3	192		8000	180	?	3470	108	108.4	72.3
GTX 1060 6	2016-07-19	$250										1280:80:48			6					?	3855	120	120.5
GTX 1070	2016-06-10	$380	150W						GP104	7200	297	1920:120:64		1683	8	256			256	?	5783	181	180.7	96.4
GTX 1070 Ti	2017-11-??	$	W									2432:152:64	1607						256	?
GTX 1080	2016-05-27	$600	180W									2560:160:64		1733			GDDR5X	10240	320	?	8228	257	257.1	102.8
GTX 1080 Ti	2017-03-05	$700	250W						GP102	12,000	471	3584:224:88	1480	1582	11	352		11000	482	?
Titan X	2016-08-02	$1200										3584:224:96	1417	1531	12	384		10240	480	?	10157	317	317.4	136
Titan Xp	2017-04-06											3840:240:96	1405	1582	12			11410	547.7	?	10157	317	317.4	136
Tesla V100	2017-06-21	$	300W			2.1?		Volta	GV100	21,200	815	5.376:0:0	TBA	TBA	16 32	4096	HBM2	900	900	TBA	TBA	TBA
GeForce	2018-Q2	$	W	12.0 (12_1)	4.5	2.1?	1.0	Ampere?	GA104	?	?	TBA	TBA	TBA			GDDR5/GDDR5X/GDDR6			TBA	TBA	TBA	TBA	TBA

Close

Direct3D is a proprietary API only available on the Microsoft Windows family of operating systems. Direct3D 12 is only available on Microsoft Windows version 10 and on the the Xbox One. Vulkan is available on Microsoft Windows 7–10, Linux and Android 7 Nougat and it may be available on the PlayStation 4.

• ¹ Single-precision shader processors : texture mapping units (TMUs) : render output units (ROPs)
• ² The processing powers are calculated, i.e. theoretical values! See e.g. Maxwell (microarchitecture)#Performance.
  • The theoretical half-precision processing power of a Pascal GPU is 2× of the single precision performance on GP100 and 1/64 on GP104.
  • The theoretical single-precision processing power of a Pascal GPU in GFLOPS is calculated as 2 (operations per FMA instruction per CUDA core per cycle) × number of CUDA cores × core clock speed (in GHz).
  • The theoretical double-precision processing power of a Pascal GPU is 1/2 of the single precision performance on GP100, and 1/32 on GP102 and GP104.
• ³ The fillrates are calculated i.e. theoretical values!
  • The Pixel fillrate as the number of ROPs multiplied by the base core clock speed
  • Texture fillrate as the number of TMUs multiplied by the base core clock speed.
• ⁴ The obtain comparable benchmark values, the everything but the graphics card has to be identical: the other hardware (CPU, RAM, …) and the software (OS, graphics device driver version, game patch level, …)

More information Model, Launch ...

Model	Launch	Release Price (US-$)	TDP (watts)	API support (version)				Chip				Core config1	Clock rate			Memory configuration				Fillrate		Processing Power (GFLOPS)
				Direct3D	OpenGL	OpenCL	Vulkan	Arch	Name	Transistors (Million)	Die Size (mm2)		Core (MHz)	Boost (MHz)	Memory (MT/s)	Amount (GiB)	Bus width (bit)	DRAM type	Bandwidth (GB/s)	Pixel (GP/s)2	Texture (GT/s)3	Single Precision	Double Precision
HD 7730	2013-04-??	$60	47W	12.0 (11_1)	4.5	1.2	1.0	GCN 1st gen	Cape Verde LE	1500	123	384:24:8	800		1125	1	128	GDDR3 GDDR5	25.6 72	6.4	19.2	614.4	38.4
HD 7750	2012-02-15	$110	55W						Cape Verde PRO			512:32:16	800 900		800 1125	1 2 4		GDDR3 GDDR5	25.6 72	12.8 14.4	25.6 28.8	819.2 921.6	51.2 57.6
HD 7770	2012-02-15	$160	80W						Cape Verde XT			640:40:16	1000		1125	1 2		GDDR5	72	16	40	1280	80
HD 7850	2012-03-19	$250	130W						Pitcairn PRO	2800	212	1024:64:32	860		1200	1 2	256		153.6	27.52	55.04	1761.28	110.08
HD 7870	2012-03-19	$350	175W						Pitcairn XT			1280:80:32	1000		1200	2			153.6	32	80	2560	160
HD 7870 XT	2012-11-19	$270	185W						Tahiti LE	4313	352	1536:96:32	925	975	1500	2			192.0	29.6	88.8	2841.6 2995.2	710.4 748.8
HD 7950	2012-01-31	$450	200W						Tahiti PRO			1792:112:32	800		1250	3	384		240	25.6	89.6	2867.2	717
HD 7970	2012-01-09	$550	250W						Tahiti XT			2048:128:32	925		1375	3 6			264	29.6	118.4	3788.8	947.2
HD 7790	2013-03-22	$150	85W	12.0 (12_0)		2.1		GCN 2nd gen	Bonaire XT	2080	160	896:56:16	1000		1500	1 2	128		96	16.0	56.0	1792	128
R9 290	2013-11-05	$400	250W						Hawaii PRO	6200	438	2560:160:64	947	—N/a	5000	4	512		320	60	152	4848.6	606.1
R9 290X	2013-10-24	$550							Hawaii XT			2816:176:64	1000	—N/a	5000	4 8				64	176	5632	704
R9 285	2014-09-02	$250	190W					GCN 3rd gen	Tonga PRO	5000	359	1792:112:32	918	—N/a	5500	2	256		176	29.4	102.8	3290	206.6
R9 380X	2015-11-19	$230							Tonga XT			2048:128:32	970	—N/a	5700	4			182.4	31	124.2	3973.1	248.3
R9 Fury	2015-07-14	$550	275W						Fiji Pro	8900	596	3584:224:64	1000	—N/a	1000	4	4096	HBM1	512	64	224	7168	448
R9 Nano	2015-08-27	$650	175W						Fiji XT			4096:256:64	1000	—N/a						64	256	8192	512
R9 Fury X	2015-06-24	$650	275W									4096:256:64	1050	—N/a						67.2	268.8	8601.6	537.6
RX 460	2016-08-08	$110 (2GB) $140 (4GB)	<75W					GCN 4th gen	Polaris 11	3000	123	896:56:16	1090	1200	7000	2 4	128	GDDR5	112	17.4	61	1953	122
RX 470	2016-08-04	$180	120W						Polaris 10	5700	232	2048:128:32	926	1206	6600	4	256		211	29.6	118.5	3793	237
RX 480	2016-06-29	$200 (4 GB) $240 (8 GB)	150W									2304:144:32	1120	1266	7000 8000	4 8			224 256	35.8	161.3	5161	323
RX Vega 56	2017-08-14/28	$400	210W					GCN 5th gen?	Vega	12,500	486 mm²	3584:224:64	1156	1471	1600	8	2048	HBM2	410	74.0/94.1	258.9/329.5
RX Vega 64	2017-08-28	$500	295W									4096:256:64	1247	1546	1890				483.8	79.8/98.9	319.2/395.8

Close

¹Shader ALUs : Texture Mapping Units : Render Output Units

Linux kernel-based family of operating systems

• Linux as platform mainly use cases on personal computers (PCs), not on mobile embedded stuff
  • merge: User:ScotXW/Sandboxes on Linux, with sufficient man-power, you can maintain pretty much anything out-of-tree and work with very old kernels; Pro? stability. Con? old software.
  • Distributions-unabhängige Anwendungen für Linux
• Instead of distinguishing based on the hardware, I distinguish based on the use case. All the following runs on a personal computer but comes with very different requirements:
  • Linux for at home necessitaes User:ScotXW/kdbus/cgroups to bring sandbox and klik
  • Linux for the office: a perfect match: no need to play BluRays, none of the "not-free-enough" problems, no hardware problems, etc.
  • Linux as gaming platform stationary, for mobile see whatever runs on the Pandora/DragonBox Pyra/etc.
    • merge: Developing video games for Linux
    • merge: Playing video games on Linux
    • merge: User:ScotXW/Rendering APIs

• refer to: Advantages and benefits of free and open-source software
• refer to:Legal aspects of algorithms "software patents" should be rather called "patents on algorithms"
• reuse: User:ScotXW/Quotes Referenced quotes for reference

• What a kernel does: the bootloader GNU GRUB does not duplicate kernel functionality: to execute the Linux kernel, it simply copies the binary file to be executed into RAM and then tells the CPU to execute it (thereby ending/destroying it's own instance?). When instead the Linux kernel is asked to execute a program, its own kernel threads keep running in the background. Actually the program could not be executed without the Linux kernel running.

• since Linux 4.8 conversion of the drm and media documentation from DocBook to Sphinx doc format: https://www.kernel.org/doc/html/latest/sound/soc/overview.html; there was writing about this on LWN.net.

Software development

• »Sounds good ... when can we start using it?«  – anybody
• »A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.«  – Antoine de Saint-Exupéry
• »Good designs arise only from evolutionary, exploratory interaction between one (or at most a small handful of) exceptionally able designer(s) and an active user population.« – unknown
• »Nine women can't make a baby in one month.« or »Adding man-power to a late project makes it later« – Brooks's law see his book "The Mythical Man-Month"
• most FOSS projects are do-o-cracies, the person who does decides
  • Upstream should always be the driving force forwards thus carrying the most modern code as well as being the decisive factor when it's time to obsolete things from their code base
  • Downstream should carry the burden of maintaining legacy code, if they choose to stick with it
• We fix things where they are broken, never tape over them!
• »Mozilla Corporation isn't a company that's trying to win the market. It's a community that's trying to change the world.« – Richard Newman, here ... by holding a certain market share, because if people don't actively use Firefox, they obviously do not care about the world changing stuff
• From 2014 onward, "we" can push for more FOSS for proprietary walled gardens (cf. e.g. Category:Windows-only free software) or "we" rather push for an FOSS and open platform operating system, i.e. Linux API, OpenGL, Simple DirectMedia Layer, Wayland + XWayland, KDE Plasma 5 / GNOME Shell / Cinnamon.
  • Having some key software running on the walled gardens as well, is of course good, e.g. VLC media player, Firefox, Subsurface, etc. But is there a point in porting every software?
  • Looking at the history of Microsoft involving themselves in avoiding the growing of market share/installed base of competing products (operating systems, office suites), maybe it is about time to concentrate more on developing and establishing "Linux", as a free and open-source AND open platform for FOSS and for proprietary software. Looking at Apple's successful digital distribution software and how they forbid GPL'ed software in it...
  • Programming Linux-only would create unique selling propositions for this platform, and while such may be regarded as "rude" and "impolite" towards other free and open-source operating systems, it should be decided on the technical merits. Comparing the Linux kernel–user space API with other such APIs, does it offer advantages to the programmer? For example netsniff-ng, Weston and systemd are Linux-only software, because their authors preferred the "Linux kernel–user space API" over POSIX/UNIX because of the technical advantages.
• Approaches to writing software:
  • "write software": from top to bottom, an algorithm with some IF-statements; ideal for small programs to be written by a single person scratching an own itch
  • "build software": like assembling building blocks; combine black-box subsystems written by different individuals with one another;
    • the specifications must have been explicit about what functionality each subsystems must have; yet it sill happens that author of subsystem A assumed some function will be in subsystem B and not in A
    • the interfaces between the black-box-subsystems are not perfect;
    • subsystems are like black-boxes because even though the source code is available, the author may not be, so until somebody else has worked himself though the source code of that subsystems it is factually a black-box for everybody else, especially for the team assembling the end-system! They HAVE TO rely on the specs being aboded by. Even though the author is available, in case something does not work as specified (or intended?), there needs to be communication with that author without further misunderstanding.
  • "let software grow": start with the main loop, and implement subsystems one after the other, do take missing subsystems into consideration by stubbing them out. That idea behind this approach is the possibility to test immediately in concert. Test while the system grows, instead of not until all the subsystems are ready. What this approach does is to minimize the possible amount of bugs introduced with each new LoC. The early tests show bugs early and makes them easier to find. Now because software IS complex, it is of course still possible that something new interacts in a faulty way with code written early. Depending of how well subsystems are isolated from one another, and of the sequence the subsystems are added to the main loop, this becomes less likely. This approach is not possible when using only already written subsystems.
    • Testing subsystems independently does not reveal any of the bugs or missing functionality that only make themselves noticeable when all (are supposed to) work in concert.
• source code in high-level language pretty much represents the intention of its human author; given a high enough amount of source-code and enough individual authors, assembling a new software from such subsystems is already quite demanding. To make things really complicated, this all has to be compiled into machine code, then executed on some computer in the context of some operating system.

Quotes

• Idiocracy-style advertisement like for Tarrlytons/Tarrlytons won't do much good to Linux
• http://simpsons.wikia.com/wiki/Shelbyville
• Zapp Brannigan: "... then for all I cared they could sit around the whole day drinking beer in their underpants"
• NASA-guy: ".. we got to find a way to make this fit into the hole for this, using nothing else but that" in Apollo 13
• In case you want to know what a producer is responsible for, watch Wag the Dog; no, there is no Oscar for producing...

Whatever

• User:ScotXW/GNOME_braindamage – why?
• User:ScotXW/FOSS – messy to find stuff
• User:ScotXW/Media Players (free and open-source software) – not as good as Software audio players (free and open-source)
• User:ScotXW/Virtualization
• I turned GNU GRUB into GNU GRUB
• I turned LAMP into LAMP. It lacks a link to Special:Permalink/578391107 so we remove content duplication
• Optimal cutting temperature compound what a useful article!
• I was bold, renamed the article "GUI widget" into Graphical control element (software) and rewrote its introduction.
  • Ach, I just wrote my own: User:ScotXW/Graphical control element
• GNOME Maps, Klavaro, Shutter (software); User:ScotXW/Klavaro, User:ScotXW/GNOME Maps, User:ScotXW/SDDM, User:ScotXW/Font-Manager, User:ScotXW/Glx-Dock
• User:ScotXW/Voice interface
• User:ScotXW/Shell (computing)
• User:ScotXW/Dietary fiber
• User:ScotXW/systemd
• User:ScotXW/dma-buf
• User:ScotXW/DNF (software)
• User:ScotXW/Template:Wayland

Android – market share

Debian – configuration beyond my competence and understanding

To deal with more complex situations, a configuration must be complex itself. Is it possible to either hide away some of that complexity, or to rather adopt a solution, that does not cover complex situations and and is therefore simple and plain? As long as blindly fol­low­ing on-line guides works…

A simple situation is a single user using Inkscape/etc work on his desktop computer. In case fast-user switching goes hand in hand with a sane plumbing layer, so be it. Other then that, fast-user switching is no priority here.

Most Linux distributions are far beyond the understanding and competence of most private end-users… Examples:

• GNU GRUB's /boot/grub/grub.cfg shall not be edited directly, because it is replaced in case of some kernel-update. Being already confusing itself, the user is forced to edit files in /etc/grub.d instead. Well, while I am able to edit grub.cfg to change e.g. the back-ground image, I am sadly too stupid to achieve this by editing some file in /etc/grub.d => no customizing GRUB for me, e.g. add amdgpu.powerplay=1 or nouveau.pstate=1
  • Why is that? In this case, how else to solve the given problem? Maybe GRUB3 will be able to deal with that without having to rely on shell scripts parsing shell scripts.
  • Additionally and in general terms, because Debian does not explicitly address the simple (and less competent) end-user installing Debian on his desktop computer. Debian is regularly and on a broad bases installed on HTTP servers and maintained by seasoned computer administrators… these setups require more complicated settings and don't care about the added complexity.
• systemd's three-level configuration: it was implemented that way, to support even complicated and unusual setups. For the not-so-typical Linux desktop end-user, this ads serious and – for him – totally unnecessary complexity to the basic configuration of his operating system. What's wrong with systemd being that way? Absolutely nothing! It is the Linux distribution that could address this "bloated complexity for the simple desktop end-user problem".
• configuring your network interfaces: /etc/network/interfaces vs. systemd-networkd vs. NetworkManager vs. ConnectivityManager vs. ConnMan:
  • NetworkManager is meant for your mobile computer (laptop) to deal with WLAN
  • systemd-networkd is meant for containers and all sorts of complicated setups
  • /etc/network/interfaces is meant for the typical stationary computer: as simple as possible, reliable and strait forward.
• /etc/crontab vs. /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.monthly/ /etc/cron.weekly/
• /etc/fstab vs. udisks vs. systemd-mountd
• using iptables directly in some shell script vs. using all sorts of wrappers
• sysv-rc-conf gives you an overview over ALL daemons/services started by init over all run-levels!! I am missing such a simple tool for systemd.

Why abandon working solutions?

1. Because the replacement solution is better for YOU!
2. Because YOU want to play the guinea pig for the new solution, though it does not suit you!
3. Because YOU want to obsolete your acquired and readily available knowledge, in favor of the new solution…

Conclusion: To be able to handle the operating system running on the desktop/laptop computer, it may prove much more productive for the typical office/home computer user to learn this, by bothering with Linux From Scratch or Arch Linux instead of starting to learn the – from his perspective totally bloated – Debian configuration.

Why use GIMP when Tux Paint would suffice?

Differences of opinion

Despite being full of marketing horse shit up to the point where something is being explained from the view point of some marketing guy, I came upon something I perceive as a serious problem when looking up Wikipedia articles around computer terms, e.g.

A computer file is en entity that is part of a file system. Nothing else. The notion of a computer file was created by the way we store data on persistent storage devices. To further comprehend the terms "directory", "file name", "file format", "file attribute", I would leave the abstraction layer and explain them on the basis of a concrete file system: e.g. ext4.

• Question_1: How is my data stored on my hard disc?
• Question_2: How do I interact with my data?

A "Command-line interface" is a kind/type of Human-machine interface, others being e.g. GUIs, TUIs, Voice-command interfaces, …

• Is the interface of a "command-line interpreter", e.g. bash, csh, …
• Is the interface offered/provided by the "command-line interpreter" to the computer user sitting either at the computer keyboard in front of the computer screen or sitting in front of some teletypewriter ;-)
• deterministic feature no1: the notion of files (One deterministic feature of a GUI could be the the notion of icons (cf. WIMP paradigm.)
  • most common use case is to call upon (i.e. execute) individual programs that are available as individual files by typing their file-name maybe augmented with some command-line options and pressing ↵ Enter.
  • To facilitate this calling upon programs available as executable files, ext2/3/4 marks "computer files" (please see my own definition above) as executable by setting a flag, the interpreters interprets the $PATH-variable where (in which directories) to search for files with the given file-name to be executed.
  • When some program is said to have a command-line interface, this usually means, that is it meant to be executed via the command-line interpreter usually involving ample command-line options. It could also mean, that the program itself, when being executed, offers the user a CLI, though this is rather seldom the case.
• deterministic feature no2: it interprets entire lines, i.e. the user enters a lot of characters (via computer keyboard or via teletypewriter), then type ↵ Enter to make the interpreter ingest, interpret and execute the entire line.
  • NOTE: A different behavior is thinkable, e.g. when each single character was interpreted immediately, making entering an entire "line" impossible. A "line" is always ended by a press of ↵ Enter, this means it can actually comprise multiple screen lines. How many characters a screen line and how many lines a screen contains depends on the "screen mode"/"video mode". Widespread are e.g. 80 chars/line and 40 lines per screen. In a script file for bash, Newline is interpreted as ↵ Enter key press unless there is also a \\ (double backslash) at the end of that line.
• Usually there is some kind of scripting language understood by the interpreter, e.g. "shell script" (NOTE: "shell script" can refer to a text-file containing a script written in shell script, or it refers to the scripting language understood by bash and consorts, "power shell script" being a different language.
• there is pwd

• Question: what is the relation between bash, GNOME terminal and the "Linux kernel subsystem", which the Wikipedia calls "Linux console" => The TTY demystified

Webcam = hardware device to be connected over USB, FireWire or similar to a Computer, in contrast oto IP cam, that is connected over Ethernet. The hardware device produces a video (motion picture) stream at a maximum resolution and at a maximum refresh rate. The data can be compressed by an appropriate ASIC and deliver a compressed video stream/signal or transmit uncompressed in RGB or YUV.

• PlayStation Eye
• http://www.golem.de/1009/77711.html "Die Videokompression erfolgt bereits in der Elektronik der Webcam durch einen integrierten Encoder-Chip, welcher einen H.264-Stream liefert."
• Image sensor can be Charge-coupled device (CCD) or Complementary metal–oxide–semiconductor (CMOS)
• A point of reference may be the image sensor of the AXIOM Alpha:
  • The CMOSIS CMV12000 Super35/APS-C video image sensor has a resolution of 4096×3072 pixel (12MP), a color depth of 12bits/pixel and is able to capture at a maximal frame rate of 300 frames/sec in 10 bit mode.^[1] It is connected to the ZedBoard over FMC.

The Xilinx Zynq Z-7020 combines a Cortex-A9 dual-core with a FPGA. The ZedBoard contains the Zynq Z-7020 and all the necessary interfaces.^[2]

• • video image sensor: CMV12000-2E5C1PA ~ € 1600,–; CMV12000-2E5C1PN ~ € 1900,–
  • ZedBoard ~ $ 475,–

The image data comes rolling out of 64 serial LVDS channels at a maximum rate of 300Mbits/sec per channel. AXIOM (camera)

DisplayPort

Resolution @ display refresh rate	DisplayPort 1.4	1.3	1.2
7.680 × 4.320 (8K) @ 60 Hz @ HDR	✓	✗	✗
3.840 × 2.160 (4K) @ 120 Hz @ HDR	✓	✗	✗
7.680 × 4.320 (8K) @ 60 Hz	✓	✗	✗
5.120 × 2.880 (5K) @ 120 Hz	✓	✗	✗
5.120 × 2.880 (5K) @ 60 Hz	✓	✗	✗
3.840 × 2.160 (4K) @ 120 Hz	✓	✓	✗
3.840 × 2.160 (4K) @ 60 Hz	✓	✓	✓

Food

More information Family, Seed ...

Family	Seed	processing
		Expeller pressing		Grinding/Milling, abrasive cutting	Mix with: Sugar, Honey, …
Asteraceae	Sunflower seed	… oil	+ Press cake	… paste	Halva
Pedaliaceae	Sesame seed	… oil		… paste	Halva, Hummus,
Anacardiaceae	Pistachio	… oil
Betulaceae	Hazelnut	… oil		… flour	+ sugar for pastry
Rosaceae	Almond	… oil		… paste, … flour,	Marzipan
Juglandaceae	Walnut	… oil		… flour	+ sugar for pastry
Fabaceae	Peanut	… oil		… paste	–
Brassicaceae	Rapeseed	… oil		–	–
Papaveraceae	Poppy seed	… oil		Poppyseed paste	+ sugar for pastry
Cannabaceae	Hemp seed	… oil		?	?
Fagaceae	Chestnut	–	–		chestnut puree/chestnut spread → Gesztenyepüré (hun) → fr:Crème de marrons (frz)

Close

There is much much room in the Wikipedia for commercial and nationalist brands and only little for basic processing… the result of Idiocracy?