Misplaced Pages

This is an old revision of this page, as edited by ScotXW (talk | contribs) at 18:19, 10 April 2014 (→User page). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Picture

Yo! Please don't add this picture:

to articles about technologies not only related to GNU/Linux. This misleads people and shows them, that for example Pulse Audio works only in GNU/Linux when it works also in other systems, FreeBSD, NetBSD, Windows among them. Free software is not only GNU/Linux. Why the hell article about for example Qt have to be GNU/Linux-centric?! Cheers. --Uniwersalista (talk) 16:23, 21 August 2013 (UTC)

I beg your pardon? ScotXW (talk) 17:06, 21 August 2013 (UTC)

The diagram also shows stuff like Ethernet. Did you also conclude Ethernet only works with Linux? Msnicki (talk) 00:08, 22 August 2013 (UTC)

Uniwersalista, I think this diagram is a harmless addition to those articles. The captions in both clearly state "here is an example of (qt|pulse) being used in the context of Linux" which is completely true, and adds useful context. The same articles say, right at the top, compatible with bsd/linux/win/osx/whatever. Nothing misleading is going on here. Now, arguably, the particular diagram in question does not add much to the PulseAudio article... since it deals mostly with visual rather than auditory elements, and does not even cover e.g. HDMI video+audio streaming, but that can be corrected by cloning and then improving the SVG. To be blunt, if you do not want the *only* block-diagram in the qt article to show qt being utilized in a linux context, then do the work to make a bsd/osx block diagram, or a win9x/winNT block diagram, which show qt in those contexts. *That* would improve the qt article in particular, and wikipedia in general; don't discourage ScotXW from doing the same. 74.192.84.101 (talk) 21:52, 27 August 2013 (UTC)

Great work on the diagrams. I have some criticisms/corrections. Not sure if this is the right place to put them? If you would prefer to chat about them elsewhere, like on the talk-pages of the relevant article, let me know. Also, if you'd rather I just edit the diagrams myself, and then upload my suggested changes for review, that can prolly also happen (I have not used inkscape but have done some simple svg editing before). Again, just say what works best for you. 74.192.84.101 (talk) 21:52, 27 August 2013 (UTC)

In this file -- https://upload.wikimedia.org/wikipedia/commons/7/7b/Free_and_open-source-software_display_servers_and_UI_toolkits.svg

1. Typo , noveau ==> nouveau 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

Yes.

2. Misrepresentation of current state (wikipedia is not a crystal ball), X-Server is the 'display server' as of 2013, whereas Wayland is the 'alternate display server'. It first shipped in FC17 of mid-2012, and won't even be the default for fedora until mid-2014 and FC21, says the Wayland article. That ignores non-fedora distros, including RHEL/centos/sciLinux from redhat themselves, as well as non-RPM distros like Ubuntu, which may *never* have wayland as the default display server. Strongly suggest that you put X-Server where it belongs, in the 'display server' box. Less strongly, recommend that you create a third category named something like 'upcoming display servers' that can include wayland for fedora and mir for ubuntu, since both of those choices are Sourceable Predictions From Notable Persons. Hmmm... it looks like you are already dividing the chart up into three sections, one for android, one for FutureUbuntuWithMir, and one generic section which is supposed to be GenericLinux but looks to me like FutureRedHat in many ways. Maybe you should have a four-section chart, with top-left GenericDesktopLinux (to include UbuntuPre2014 and FedoraPre2014 flavors) using X-Server, top-right AndroidMobileLinux, bottom-left RedHat2014+Linux documenting Wayland-related changes, and bottom-right Ubuntu2014+Linux documenting Mir-related changes? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

NAK. I am pretty sure, that no noteworthy changes are going to be made to the article or to the diagrams until 2016, because the people don't care. They don't care about Guantanamo and they sure don't care about the "Free desktop". I have no plans of keeping it up-to-date, so I simply depicted the stuff that is gonna be the standard. Debian, Kubuntu, Xubutu, mer: they all want systemd, pulseaudio and most definitely wayland.

Well, fair enough. I may try to create a modified version, now that I understand better what you are trying to convey here (see my comment below under #6). Do I just download the SVG, and open it in inkscape? Ubuntu 12.04.2 installed at the moment here. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

p.s. The_People c'est moi! I care about gitmo. I care about libre. But yes, I hear you, sometimes those qualities seem like rarities. Do not give up the fight.

3. Suggest adding some lines-and-arrows to the diagram, to show dataflows. From what I can gather, Qt can target Xlib or libGL or libwayland-client. Is there some way to cleanly make that clear in the diagram? There does not seem to be any stuff shown in this particular diagram at the moment that shows the libGL pathway, e.g. qt-to-libGL or cairo-to-libGL. Those will still exist under wayland, right? And they certainly exist now, although I'm not sure how often such pathways are utilized. Similar comments about SDL&maybeClutter-to-EGL, that pathway-option should be shown explicitly, with lines-and-arrows. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

NAK. This diagram is supposed to be an overview depicting pretty much everything available as of components of the free desktop (now and in the foreseeable future). If you want pathways, I suggest you create derivative diagrams for GNOME/KDE SC/etc only, there you'd have the additional space for pathways. There is no space here, it is already pretty crammed. But yes, pathways with even more details are good.

4. The large collection of system daemons looks extraneous to me. Sure, in some fashion I suppose that 'display servers & ui toolkits' depend on the low-level stuff like upower and NetworkManager... in the same sense that they depend on the bootloader and the BIOS, cause if you cannot even boot, you obviously cannot run gedit! Seriously, though, the daemons seem out of place. Removing some/many of them would declutter the diagram, and also give room for lines-n-arrows of suggestion#3, above. Did you intend for those particular daemons to be listed in this particular diagram, for some reason? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

NAK. The daemons are pretty much important, because a) many user are not aware that Network-Manager or PulseAudio are in fact primarily daemons, and they only see and interact with the GTK+/Qt surfaces for these daemons, and only by clicking some buttons. Utilizing the CLI exposes more functionality and also, makes the daemons interesting for non-GUI setups. E.g. OpenWrt uses PulseAudio, that is the PulseAudio-daemon! Instead of the NM they use something called netifd, but that would take too much space ;-) And b) because they represent the ongoing effort to combine resources. GNOME and KDE SC (and also the other DEs) all share this code. Especially KDE should learn to solve problems upstream instead of working around such problems inside of KDE...

I wasn't going to bring up TUI-based apps, like parted / mc / mutt / ncurses stuff, but in many ways that is another "ui toolkit" for the free desktop, or at least, the rescue-disks when the free desktop goes awry. If I make derivative diagrams, I may try adding those in. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

5. Not sure that lima/etna_viv/freedreno/tegra-re actually belong under wayland... as opposed to under android... they almost certainly don't belong under X-Server. Aren't those all android-only GPUs? Or is wayland intended to challenge libbionic and libEGL in the ARM-tablet market, not just X-Server in the x86_64-desktop market? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

They don't. These are just Linux kernel modules, like ath9k or Netfilter are. I want no pathways, but I do want the mention some Kernel modules there. So when somebody has look at File:Gallium3D_example_matrix.svg or File:Linux Graphics Stack 2013.svg, or at some diagram with more details he or she has a better chance to distinguish between stuff that belongs to kernel space and stuff that is in user space. He or she can also port info back to this diagram.

mer-based stuff like Sailfish OS will use lihybris and Android-drivers where there are no Linux drivers available, not only for graphics, but also for hardware like the GPS-receiver. And yes, they also use systemd and wayland on embedded systems.

Who is using wayland on embedded systems, and what systems? Surely not Tegra2, right? Is google planning on junking libbionic and switching to the 'same' wayland that will be found in RHEL9, for instance? (These are all honest questions... I had no idea anybody foresaw wayland as a useful system for tablet & smartfon devices.) Update, I did a little looking around before submitting my reply -- wayland can implement custom backend display drivers, and one has been created for RaspberryPi devices, see here . I'd be *very* curious to know whether they used the Hermitage/Gottschlag/Mansell open source driver stuff, or just got a binary-blob-backend. This will give us a hint as to how libre the future under wayland is likely to be. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

1. Before Nokia lost its mind and turned to the evil, they paid people to play with X.Org-stuff to make it run better on smartphones. Jolla was founded by ex-Nokia employees.

2. Smartphones come with 512MB and more of DDR3 main memory and quad-core CPUs. That is **very** powerful hardware compared to 1992: i486 and 4MB of DRAM (fast page not EDO)

3. Wayland is **much** simpler then even X11 core protocol. And it performs **much** more better then X11! The LCA2013-Video by Daniel Stone explains it well enough. So yes, the same implementations of the Wayland protocol runs on Dekstop, Nettop, Tablets and Smartphones! The exact same it true for systemd. Only OpenWrt-folks do not run systemd: OpenWrt architecture because they don't have many processes and also, because procd runs better on only 32MIB of main memory. It also seems like procd lended many ideas from systemd.

6. Ought to add 'intel' to the kernel-mode-libdrm-gpu-driver listing, next to radeon & nouveau. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

ACK. Indeed I forgot to mention the free and open-source Intel drivers, even after watching Keith Packard (who "does not care for anything else" and is heavily involved in DRI 1,2 and 3)

Many of my comments above were based on an incorrect assumption. You said above: "This diagram is supposed to be an overview depicting pretty much everything available as of components of the free desktop." But the filename is simply Free_and_open-source-software_display_servers_and_UI_toolkits , which is what confused me. Suggest changing the filename to something like this -- Free_and_open-source-software_components_of_the_graphical_desktop ... that way, including PulseAudio and systemd makes perfect sense. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

In this file -- https://en.wikipedia.org/File:Gallium3D_vs_DRI_graphics_driver_model.svg

1. Suggest changing 'Gallium3D device driver' into something like 'Gallium3D-compliant driver' , and maybe giving the names of some major targets (r600/nc50/i965/etc). As I understand it, there is no actual "gallium driver" but merely the interface-spec, which says that e.g. the r600 driver must present a specific gallium3d-tracker-interface to the upstream mesa-opengl-implementation-library, and also that is must present a specific gallium3d-winsys-interface to the libdrm stuff in the kernel. Is this right? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

ACK. Technically it would be correct to speak of Gallium3D-complient device driver. NAK. Because I already created a Gallium3D-Matrix: File:Gallium3D_example_matrix.svg; Please do note how crucial it is to be able to distinguish between Kernel space and Userspace when looking at gaphics drivers. This diagram: File:Linux_Graphics_Stack_2013.svg mentions at least Wayland, but it lacks Gallium3D!!! Would definitely be a nice to have!

Actually, for my own understanding, as well as for improving wikipedia, I'm currently trying to figure out the difference between the "graphics drivers" on Linux. There appears to be the DIX/DDX layer (the xserver-xorg-video driver) which nowadays has maybe been replaced by the MesaStateTracker layer(?), the Gallium3D layer (translates from GLSL to TGSI ... and maybe from TGSI into R600G?), and the libDRM layer (which talks 'directly' to the GPU hardware). I'd like to know, at some reasonably detailed level, what each of these 'boxes' is supposed to accomplish. I'd also like to compare that to the proprietary-binary-blobs, which don't seem to use *any* of that infrastructure -- yet they still internally provide an openGL implementation , and get from the X-server to kernelspace (somehow), and drive the GPU hardware (somehow). But first I'm just trying to grok how the open-source ones currently work, which is apparently not such an easy task. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

2. Along the same lines, I think it would help if the 'drm' box on the bottom right mentioned specifics (libdrm-radeon / libdrm-nouveau / libdrm-intel). 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

Yes, it would indeed help. And e.g. the Debian repos only contain these three: Nothing else. Do you know why?

Although I do not 'know' why I think I can speculate on why: older DDX/DRI2 drivers for matrox/3dfx/whatever were pre-DRM, and there are no libdrm kernel-mode drivers being implemented for the old hardware (and the companies themselves have disappeared in favor of the triumvirate of nvidia/amdNeeAti/intel ... at least on the desktop). By contrast, companies that are making new GPU hardware at the moment (adreno/tegra/friends) do get libdrm implemented for their stuff. As for other semi-modern ways of accessing the display, like the vesa-framebuffer drivers and such (there is also radeonfb and many more), those don't use libdrm because the talk to the GPU via x86 BIOS calls, "invented" back in 1987 when DOS was king. Your diagram is mostly about the graphics&toolkit stuff when the system is fully booted, but there are some weird things that happen during the grub bootloader stage, and the plymouth bootscreen, and so on. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

3. What about the kernel-mode 'dri' box on the righthand side? Is there still DirectRenderingInfrastructure stuff in the kernel, that is actually used by r600 and similar gallium-compliant drivers? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

I do not know for sure how Gallium3D-complient drivers communicate with the hardware! I am pretty sure, it is via the DRM. But the DRM is hardware specific...

My limited understanding is this: the gallium3d layer converts GLSL subprograms into somewhat-generic TGSI, and then the kernel-mode hardware-specific-driver compiles that TGSI into a binary form which is specific for the target GPU vertex-shader/geometry-shader/pixel-shader units, before passing it along to the GPU hardware. Communication with the GPU hardware is done via the PCI-e bus, for discrete GPUs at least: there are some areas in dram which are mapped to the vram, not just for the framebuffer-data containing pixels, but also for the various registers/shaders/etc that are used to configure and setup the GPU. I'm very fuzzy on the details, though, and this info might be outdated. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

4. Along the same lines, does the 'drm' box on the *lefthand* side belong? I was under the impression that the older DRI2/DDX drivers did not need/use libdrm. Am I wrong? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

I do not know, but yes, there were a couple of implementations for X graphics drivers!!!

X11R5 : one DDX per system, used OS-Specific kernel interfaces also supported non TCP/IP network protocols (decnet,...)

XFree86 2 & 3: one DDX for all systems with os-support layer, direct hw access to VGA cards, avoiding complex kernel interfaces for video card support

XFree86 4: added the OS-independant modules loader

X.Org 7 started removing support for older, non POSIX, non TCP-IP systems (VMS, DECnet, OS/2,..)

Remove direct hw access (KMS, DRI2)

And I will rather spend time working on Wayland/DRI3/Gallium3D then on X11! My current system is running X.Org Server, but I can hardly wait to get rid of the geriatric X :-)

Watch this Video: http://www.youtube.com/watch?v=cQoQE_HDG8g and you will understand why! We have 2013, if nobody has bothered to document X better until now, I sure as hell won't. ;-)

I think perhaps Heinlein said it best: by the time you understand some technology reasonably well, it is already obsolete. (He added, luckily you normally learn a thing or two from all your trouble with the old technology, things which can be applied to the new situation... or we'd still be living in the trees.) I skipped the video, but I went through the Feb'13 slides. Here is more recent Jul'13 info from the same folks. In particular, I note that every wayland system will include an embedded X.org Xserver, for backwards compatibility with existing X-client-apps. Furthermore, the future-is-wayland is far from confirmed, as you can see from this reply by Eric Griffith (one of the main wayland folks apparently) in the forums. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

Point being, may I continue to gently suggest that your diagram does not really have NPOV as regards wayland vs X11, and is suffering from a mild case of WP:CRYSTAL. The current free desktop is X, and in the foreseeable future (now through 2015 or even 2020), even should wayland become ubiquitous somewhere under the hood, and mir disappear, many *apps* will still be X clients. Depending on what nvidia et al decide to do, see eric-link, and how well nouveau keeps up, and how important android/tegra/adreno/powervr/etc become, the diagram as it is now might turn out to be wrong. Better to stick with what we know, and mark things that are still in the future as *being* in the future. Hard to do that without cluttering the diagram too much, or growing it to 6000x6000 pixels.  :-) I'll give making a derivative a shot when I have some more time, though. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

Also, KMS is not in your diagrams at the moment, right? Is is still a wrapper around libdrm? Or is it older than that, and only worked with DRI2 drivers? (which are still present of course) 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

5. In the big usermode 'dri' box are there any current examples? Some of the open source intel drivers are still non-gallium, methinks, so maybe list their names. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

AFAIK Intel is not going to write Gallium3D-drivers! Intel-guys write and support only DRI-drivers. Other people took the code and ported it to Gallium3D. The Matrix depicts the idea behind Gallium3D pretty good, I hope, but actually we do not have a Direct3D 10/11 tracker! There is a Direct3D 9 tracker, which boosts performance with Wine a great deal. Don't know how much performance we loose by implementing more and more Interfaces though...! Additionally we also loose some of the possibilities of the hardware... because the hardware driver is written for the hardware, but is only allowed to talk over the WinSys-Interface.

I'm curious about the intel-drivers-ported-to-gallium3d, for my own system. Do you have a link, or a keywork-hints, for where I can find that stuff? 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

I think X has harmed the entire Free Desktop very much. No, only by reading Misplaced Pages-articles you do not and will not see that fact. It took people like Keith Packard (excluded out of XFree86, founded X.Org) to allow this fracking protocol-kraken to be replaced, and also Companies willing to pay developers real money to get something that could compete with the iPhone... They worked on X.Org and did a lot of good things to it, but Wayland will be the actual thing. As a user you won't notice the transition, but developers will! We are definitely getting there. Question is: why did it take so long to get there? Cannot be lack of dedication. Who decided to not touch the X11-core?

The same is true for OpenGL! OpenGL was superior to Direct3D and could have stayed superior, but it didn't! Also, Mesa only supports OpenGL 3.2, whereas OpenGL 4.2 is available! Thanks to Mac OS and Valve OpenGL could start to matter a lot more. Developers claim that is is easier to develop for OpenGL and then port to DirectX. However, Games are rather developed for Consoles, and drivers are rather being written for Android! Too late for a Desktop Linux Spring?

I just stumbled over something: Freedreno: I think this drm-freedreno is a DRM-Kernel module for the Adrenos. And he says, he additionally has "a libdrm branch with libdrm_freedreno for userspace updated to work on top of either this driver or the downstream android kgsl+fbdev drivers.

1. DRM is hardware specific,
2. libDRM here File:Linux_Graphics_Stack_2013.svg could be the DRI-driver here File:Gallium3D_vs_DRI_graphics_driver_model.svg. So Gallium3D takes userland libDRM-nouveau and splits it up into three chunks of code, and adds code for the Galliudm3D Tracker Interface and for the Gallium3D WinSys Interface (File:Gallium3D_example_matrix.svg). It still requires a Kernel-module to talk to the hardware, and this is the DRM, which is also hardware specific.
3. I'd like to know, how libDRM talks to lib-mesa-glx / lib-mesa-dri!
4. Also, I think, the userland-part of the drivers talk to the DRM (a Kernel module) by implementing the glibc. While the userland-drivers for Android do the same by implementing libbionic. Thus libhybris will translate bionic-calls to glibc calls, making it possible to use those drivers with cooler Linux-based systems than Android ;-).

Yes, from what I can tell Freedreno is definitely an open-source reverse-engineering project for the Adreno GPU. There are similar projects for the ARM Mali GPU (lima), the vivante GPU (etna_viva), the nVidia Tegra GPU (tegra-re), and so on. Most of these GPUs are not used in desktops, but only in tablets and such, which means they tend to run Android. Broadcom makes the Videocore GPU, as used in RaspberryPi. See here. Just like with nvidiaBlob-vs-nouveau GPU and amdBlob-vs-radeon GPU on the desktop, there are also binary-blob drivers for all these tablet GPU options. Intel desktops are the exception; not sure about their Atom-based GPUs, though. Only lima is performance-competitive at the moment, from what I can grok. 74.192.84.101 (talk) 21:57, 28 August 2013 (UTC)

Many many thanks for the diagrams

For ages I have been looking for diagrams and overviews of the Linux desktop stack. I've read plenty of overviews about the Linux server stack already; the so called LAMP stack, Linux+Apache+MySQL+PHP (PHP or Perl or Python). Those diagrams you created are really very very useful work. Viele danke :-) Maybe I'll find some time to improve one or two diagrams, or to add an MS Windows + KDE stack diagram for the Qt article. I immediately saved some of your diagrams to my harddrive and added it to my personal notes about Linux. Paulus/laudaka Laudaka's talk page 07:02, 31 August 2013 (UTC)

You are welcome. ScotXW (talk) 20:30, 1 September 2013 (UTC)

Linux_kernel_INPUT_OUPUT

Linux_kernel_input_output SVG

1. propertys ==>> properties 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

2. other 'screen' types to mention are DLP-based projectors (portable-powerpoint to movie-theater-size), plus maybe OLED smartphones/signage 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

3A. the framebuffer (which is either in sdram or vram depending on gpu type) is on the 'righthand' side of the gpu next to drm/kms/gem...

Yeah, I actually did not plan to bother with such details, hence I called the box for IC-based hardware a black box, looked at the framebuffer, which is in main memory for APUs by the way, because I specifically looked at the video output. Sound is missing completely, for OUTPUT and for INPUT.

3B. ...and the physical output-connectors and their associated asic-chips (hdmi/dp/dvi/ldvs/vga/ntsc) are on the 'lefthand' side of the gpu, to drive the screen. 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

I had them in, I think they're still there on some layer made invisible, as Interfaces between IC-hardware and "Human-Sense"-Hardware.

4. strongly suggest removing sata ctrlr, it does not play a role in the user-input chain (nor the graphics-output chain)... storage & caching is another good-sized universe: doing it properly would need to cover sdram/L1/L2/L3/L4, vram/texture/L1/L2, cmos/nvram/vbios, mfm/ide/scsi/sata hdd w/ dram cache in 3.5"/2.5"/1.8" forms, sata/msata/pcie ssd w/ dram cache, hybrid hdd+ssd, floppy 8"/5.25"/3.5", cf/sd/usd/sdhc/sdxc/memstick/mmc/etc, usbkeys, usb/fwire/esata/tbolt hdds&ssds, umpteen kinds of tape-drives, SANs, NASs... and that's not even talking about storage *protocols* and cloud services and other software-ish portions of the storage world. This diagram should be about human-generated input, and human-visible output, not about generic "I/O" subsystems. 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

5. one thing not in your diagram is human-visible output sent to printers... back in the 1960s, the teletype output *was* the visual display. I think we're safe in omitting it from your diagram, though, because nowadays you pretty much always see printed output on a screen of some sort first, and then optionally print it. 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

6. optional, since the stick-figure is fine by me :-) but methinks wikimedia prolly has some stock photos of "generic humans" you could use (1 student + 1 bizSuit?) 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

7. although not typical, an interesting corner-case that might be worth adding to the diagram: audio text-to-speech software (which feeds hw spkrs/hdfons) for visually impaired folks, or just 'looking' at your eReader while driving your car 74.192.84.101 (talk) 17:44, 1 September 2013 (UTC)

This little experiment] by John Carmack inspired me to do the this diagram. Keys are the USB polling rate (when you have no USB harddisk attached to the same USB master doing some file transfers...!!!), the processing time, and then the display properties.

The display properties CRT vs. TFT vs. OLED are important because they can significantly increase response-delay. The text for this requires some space.

IC-Hardware-Black-Box. Leave it a black box and either remove SATA or add more stuff to the black-box

IC-Hardware-Structure: It could be interesting to change the black box into something with a structure, like here File:Linux_Graphics_Stack_2013.svg but with even more details. Everything runs on the CPU in the main memory, and accesses ALL the rest of the IC-Hardware through the CPU and main memory through register/memory mapping with or without the help of device drivers. Everything? Not quite, e.g. the runs an RTOS on a extra ARM9 + 96kB of separate RAM. Ubicom CPUs also have some parts of the bootloader run all the time, the Broadcom SMP stuff is also weird, and their VideoCore even more. Not sure about Qualcomm Hexagon and the Texas Instruments stuff.

Interfaces: Between Human Brain and Hardware-Hardware are the: Human-Senses. Some de:Piktogramms would be cool. Between Hardware-Hardware and IC-Hardware is the stuff you mentioned: CGA, VGA, DVI, HDMI, DiplayPort, LVDS, USB, FireWire, SerialPort, Game port, etc. Interfaces are everywhere, let's not make a big deal out of them, but let's do mention them. I like picograms and logos, because they are quickly to recognize visually.

Software: The Linux kernel is the only thing I personally care about, because that is that runs my entire hardware devices: PC, Router, Phone. At least mentioning evdev is a given, so people at least know what component to search for, when looking at Keyboard, Mouse, Gamepad, ... INPUT. I would audaciously call this general knowledge. Alternatives (for/in the Linux kernel...) should there be any, should be added, and also maybe even more details. The graphics part is obviously wrong, because I simply put KMS (Linux kernel), Graphics Execution Manager and Direct Rendering Manager there, though only ONE of them actually draws into the buffer, AFAIK. Actually which one? The diagram also omits the fact, that Wayland clients will also be able to draw into "a" buffer directly via EGL and Wayland compositors also do stuff buffer content, and do buffer-flip via the KMS.

Is `Wayland_display_server_protocol.svg' right?

Hello, ScotXW. I am afraid that the direction of arrow 2 is not correct. So does arrow 3. 128.221.224.62 (talk) 05:51, 21 September 2013 (UTC)

I just update the scheme, now it should be correct, thank you. ScotXW (talk) 09:37, 24 September 2013 (UTC)

Lennart Poettering

Congratulations on making such an impact on Linux articles. Impressed. I left a message for you about this edit Talk:Lennart_Poettering#Sources_and_quotefarm. Regards Widefox; talk 13:52, 16 October 2013 (UTC)

Thanks. But these are just the fruits of procrastination ScotXW (talk) 14:42, 16 October 2013 (UTC)

Edit comments

Hello there! I'd really appreciate if you'd be more polite in your edit comments, taking this one as a reference. I'd say my work here isn't deserved to be simply called playing. Thank you. -- Dsimic (talk) 14:01, 17 October 2013 (UTC)

Obviously there is quite some work in progress. I do appreciate spelling and grammar corrections and even more so good ideas. ScotXW (talk) 14:04, 17 October 2013 (UTC)

Well, I'd say we're on the same page — we both want to make Misplaced Pages better, especially its Linux coverage. For the beginning, would you like me to rewrite the heading section on Linux for embedded systems? It really requires a rewrite, if you agree. -- Dsimic (talk) 14:10, 17 October 2013 (UTC)

You do not need my or anybody else's permission. Just do. I'll change or revert your changes, like you mine or anybody else's. ;-)

1. The entire article Linux for embedded systems requires a different direction (i.e. Linux OSes (plural) for networking equipment, machine control, industrial automation, navigation equipment and medical instruments etc.)

2. And yes, I agree, the introduction could be way better. The entire article could. ScotXW (talk) 14:16, 17 October 2013 (UTC)

I agree there's no need for technical permissions, but then again, it's much better to reach an agreement / consensus before making some bigger changes. It should be easier and better in a long run... Team work and stuff. :)

Also, I agree that the Linux for embedded systems article should be different and much better, and there's a ton of stuff not even mentioned there — just as you above listed the categories of embedded devices. Ok, for the beginning I'll go ahead and rewrite the heading section there.

Btw, would you maybe consider creating a graph for the OpenWrt article by chance? You're really good at that, and having a nice graph there would be really good — and it could be also used for the Linux for embedded systems article. I've removed a too general "Linux overview" graph from the OpenWrt article, as it was more confusing than explanatory. Hope you agree.

-- Dsimic (talk) 14:29, 17 October 2013 (UTC)

Using that diagram was a conscious decision. Its name is Linux ubiquity. I want to show readers of the OpenWrt article, that the same Linux kernel is employed on their desktop computer or their smartphone, on several LAMP servers and (modified) on some of the worlds fastest supercomputers and vice-versa. But yes, for complete retards, it could be confusing. Also please note, that AFAIK OpenWrt contains Xfce, used by Ben NanoNote.

Before bothering to create a diagram for OpenWrt only, I'd rather bother to document OpenWrt Buildroot. Also, as can be seen e.g. here: the only relevant difference between a desktop computer and Android-devices is the fact the latter has a touchscreen as its only HID. I see no advantage in Android operating a Smart TV over, say Debian. This is my technical assessment not my opinion. Misplaced Pages articles should present and describe the underlying software architecture of things much more often and much more thoroughly than it does. It should bother less with consensuses of mere opinions of (more or less ;-)) random passersby. Because of that crap, people with the knowledge and comprehension don't bother to write text in the Misplaced Pages any longer. ScotXW (talk) 14:53, 17 October 2013 (UTC)

Sorry for my delayed response, I was busy rewriting the Btrfs#Cloning section. :)

You're totally right about the low numbers of people doing real contributions to Misplaced Pages. By saying "real", I mean the same as you described above — hard-core stuff that brings true new values to Misplaced Pages. It's really great to have everything written in formal language, polished and everything — but that's good only if there is the real stuff underneath. I mean, polishing is a great thing, but you've got to have a lump of steel in order to chrome it, right? :)

Btrfs article is a good example — the amount of real content available there is not that high, and many times in form of brief notes only — instead of thorough and up-to-date explanations. I'll try to improve that article soon. :)

I agree that, in the example you provided, Android has no real advantages over Debian or any other general-purpose Linux distribution. It's all just about the fuss how Android is great, gorgeous, yummy and such buzztalk. It's no better than CentOS (or maybe is even worse), for example, just if someone known what's he or she doing.

Just as you said, consensus is a great thing, but it depends on the involved parties. How do we know who's taking part in a "committee" discussing towards a consensus? :)

Regarding the OpenWrt article, I'll see to extend it soon so buildroot is also covered. Also, I'll think how to integrate the general Linux overview graph better into the article.

-- Dsimic (talk) 17:29, 17 October 2013 (UTC)

Disambiguation link notification for November 4

Hi. Thank you for your recent edits. Misplaced Pages appreciates your help. We noticed though that when you edited Linux adoption, you added a link pointing to the disambiguation page Amazon (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 09:09, 4 November 2013 (UTC)

Language thing

Hi ScotXW!

If you are the same ScotXW who is editing Hungarian WP, then I have a special offer to you. I scooped up a rather big en-hu dictionary and there's an experimental firefox plugin for quick word and phrase translations. If you wish to try it, then drop me a mail (try this). BR, Pkunk (talk) 22:21, 5 November 2013 (UTC)

Hi Scott! I also have offer for you. I see you are interested in linux, free software, virtualization and cloud computing. I share this area of interest with you and the topic deserves a better documentation on wikipedia, so if you want to put some content on the hungarian wiki, you can contact me directly and I will do it for you. Deal? :) --K0zka (talk) 18:01, 6 November 2013 (UTC)

Hmm, I don't know. I've heard that one should not trust a bunch of "Hungarian Barbarians". ScotXW (talk) 21:02, 27 February 2014 (UTC)

Nomination for deletion of Template:Linux layers

Template:Linux layers has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. The Banner talk 22:50, 6 November 2013 (UTC)

LAMPP Architecture Diagram for Beginners

I'm really impressed with your Diagram explanning the LAMPP architecture in bottom(low) level.

Thank you.

But for an intro to novice, beginners, I feel this might be cause confusion to them, as they new to field as this is more elobrative. Is that specific reason why removed the

from the LAMPP Software Bundle page? It serves as a quick intro to the bundle system. Kesavan (talk) 13:42, 24 December 2013 (UTC)

No, but because of the Firefox icon. There are much more Browsers available, e.g. Uzbl, Midori, Rekonq, Konqueror, or Web. ScotXW (talk) 12:29, 16 February 2014 (UTC)

Enlightenment name change

Hi ScottXW. User:kevjonesin here.

A modest request ... Please add an explanation regarding the change from "Enlightenment (window manager)" to "Enlightenment (software)" to the article's current talk page. I backtracked and eventually found your edit summary but a talk page entry would be more readily discoverable and would allow room for both a more detailed explanation for the change and for one's fellow editors to respond to such.

Perhaps in the future as a courtesy one might consider making a talk page entry first and then allow a window-of-opportunity for other editors to weigh in on 'whether' and 'what' to rename the article.

Thanks for your time and attention,
--Kevjonesin (talk) 01:38, 17 February 2014 (UTC)

The changes are justified in the edit summary. ScotXW (talk) 19:13, 27 February 2014 (UTC)

February 2014

About a couple of recent changes in Wayland article

Hello. Today you added a couple of references in Wayland (display server protocol). The first about randr extension to Weston: that's only a proposal, and probably it's not going to be accepted (see the replies in wayland-devel). The second (libinput), I think is better suited to "Weston" section than "Compatibility with X" section (because X.Org server internally using libinput has nothing to do with the compability with X protocol applications; remember: X Window System is the specification, X.Org Server is one of several implementations of such specification). --JavierCantero (talk) 19:02, 27 February 2014 (UTC)

Ah, my mistake. But, damn'it, Javier, you can't be fast enough in this software business.

Also, when can I start playing Civ5 natively on my Linux box? As far as I understand, Wayland (and DRI and all the other stuff that came so late to Linux because of X11) should make things more performant and seriously clean up the code base. That means less people are required. The means, the other people could now do other stuff, stuff that would motivate Sid Meyer to port Civ5 to Linux single-handedly. ScotXW (talk) 19:13, 27 February 2014 (UTC)

I'm afraid that Civ5 or any other game will be ported to OpenGL (over X or Wayland, really it doesn't matter) when their owners think there is profit in the Linux market. :-/ --JavierCantero (talk) 20:57, 27 February 2014 (UTC)

Re: NF graphics

Updated. -j.eng (talk) 02:15, 28 February 2014 (UTC)

{{Virtualization products}}

Hi.

I think you need to help me understand because the more I look at the edits that you did to {{Virtualization products}}, the less I understand what you did to it and the more reason to revert it all.

• First, emulators: Is emulator not another name for hypervisor? If yes, then why a separate section? If no, then what is it doing in the {{Virtualization products}} in the first place?
• Same goes with OS-level virtualization: Hypervisors do that; so why having a separate OS-level virtualization? Then again, when something is part of an OS, it is not a product.

Look, if you want to create a template that categorizes virtualization techniques vs. virtualization products, you are free to make your own template. But I am not sure if that was what you intended to do either. So, could you please clarify what I am looking at?

Best regards,
Codename Lisa (talk) 10:55, 22 March 2014 (UTC)

Oh, that template is not my work:

* First: I would not create anything with "product" in it. That is the Misplaced Pages, not the WikiMarketing. That template already existed.

* Second, I'd like to tidy up a little bit, so I parked several articles in that template, with the questionable name.

* Third, the article hypervisor distinguished between "bare metal" and "hosted" hypervirors, though it would also be rather be more interesting to distinguish between microkernelized and "full OS" hypervisors. Maybe I am going to add this classification, I haven't got to it so far. Do you want to do that, because of your expertise?

* 4th: the article Operating system–level virtualization already exists, and it explains things..., so why not link to it?

* oh an 5th: calling edits "good faith" edits does make you appear smarter only to a certain type of people... User:ScotXW 11:05, 22 March 2014 (UTC)

Hi again

1. Yes, that's true; in fact I know who made it. ;) But "product" is not a word to avoid. It is a neutral word that means something is "produced". I even used it in a Featured Article and none of the reviewers minded.
2. I guess that's exactly why I am here.
3. Mutually exclusive categorization is okay, but cross-categorization only brings confusion for our target audience: Those who do not understand where the stuff overlaps.
4. Because using it in the context of the template makes no sense. It is a technique, not a mutually exclusive genre of virtualization software. For example, Hyper-V is a bare metal hypervisor that uses operating system–level virtualization (Enlightened I/O) in Windows Server 2012. The link to Hyper-V must at the same time be in both categories.
5. Oh, I know. But then, put yourself in my shoes: I reverted your edits only because I perceived them as confusing, per WP:BRD, while I was certain that your edits were done with the intention to help. Which one of the three buttons must I choose?

Best regards,

Codename Lisa (talk) 12:56, 22 March 2014 (UTC)

# I din't suggest to avoid the work "product", I am simply no interested in working on this level. Due to laziness and time constraint I did it in this case...!

# Ok.

# I didn't say mutually exclusive categorization wasn't ok, I simply hinted that a different classification is missing!

# Yes, I should have rather created a new template simply called {{Virtualization}} and there not bother with all the wonderful "products" but rather the underlying technologies. I should have done that in the first place. BTW, isn't it odd, that such a template does not exist, but there is one for all some of the wonderful products out there? I am against deleting such attempts, but is sad. Misplaced Pages is for explaining stuff and not for marketing purposes... well, deleting it, won't bring quality authors back to the Misplaced Pages, will it?

# Oh, sorry, I can't put myself in your shoes. And as my edits should prove, I am clearly somebody who has no interested in advertising or spreading FUD. User:ScotXW 13:23, 22 March 2014 (UTC)

Hi. Your answers brings us a lot closer to a consensus. That's great. I have no problem with classifying the hypervisors in more than one categories: A native vs. hosted and a technique-based (emulators, OS-level, etc.) Of course, all of these are subcategories of hosted hypervisors, regardless of whether they are part of the supervisor or under it. (They are not above it.) We can also rename the template {{Virtualization software}} if you wish. But the reason I chose "Virtualization product" is because with this name, it can accommodate hardware and services as well. Best regards, Codename Lisa (talk) 17:52, 24 March 2014 (UTC)

Here is what I come up with: User:ScotXW/Template:Virtualization User:ScotXW 14:23, 22 March 2014 (UTC)

Ouch! A very bad idea. You are allowed to make it, without doubt, but such a name means things can come into it that you do not like. Its function and classification might change so dramatically that the reason you made it might become irrelevant. Best regards, Codename Lisa (talk) 17:52, 24 March 2014 (UTC)

Virtualization explained

From By Ulrich Gräf at Sun GmbH, in ze German language, IMO one the best explanations of "Virtualization" in the entire Internet:

• http://www.youtube.com/watch?v=1s9Se65efes
• http://www.youtube.com/watch?v=9R8H00EkQ-g
• http://www.youtube.com/watch?v=oZwnr3mQTfg
• a sniffy article can be found: http://wiki.ubuntuusers.de/Virtualisierung

Still way better, than the article Virtualization or ze article de:Virtualisierung (Informatik), though the English article is completely shit, as it explains squat. User:ScotXW 11:20, 22 March 2014 (UTC)

Hi. I will study these when I went home. Company firewall has blocked access to YouTube. Best regards, Codename Lisa (talk) 12:56, 22 March 2014 (UTC)

"Unified hierarchy" section in cgroups article

Hello there! Regarding deletion of the "Unified hierarchy" section in cgroups article, please don't get me wrong – I totally appreciate your work here, but the content of that section is simply not good enough. It talks too much about general things, without providing what actually should be provided – the description of the cgroups' unified hierarchy. Having so much "fluff" would be acceptable, but only for a section that's about five times longer than what you've provided.

Once again, please don't get me wrong, and I hope you agree. Of course, I'm more than open for further discussion. — Dsimic (talk | contribs) 03:21, 24 March 2014 (UTC)

As most of my work here, it is work-in-progress and not fire-and-forget. If you keep deleting it, it'll never grow lager. User:ScotXW 11:04, 24 March 2014 (UTC)

Understood, but can't you build it a bit further before spitting it out, so to speak? By the way, the whole cgroups article has been around for a while, and it hasn't grown that much – it isn't something that attracts a wide audience itching to expand sections. — Dsimic (talk | contribs) 14:23, 24 March 2014 (UTC)

Yes yes, I agree, it needs more "substance" to quote Kissinger, and doing work regarding it in some user-space won't make it better. Also, development was just picked up again, by Hejun Teo et al. Major changes like the mentioned unified hierarchy is underway. So devel is work-in-progress and so is the article. User:ScotXW 14:28, 24 March 2014 (UTC)

On the other hand, and according to WP:NOTNEWS, we should either wait for things to reach their production stages, or wait until there are reliable sources available. Hope you agree. — Dsimic (talk | contribs) 17:38, 24 March 2014 (UTC)

The sources I quoted are as reliable as they can get... User:ScotXW 17:38, 24 March 2014 (UTC)

No doubt about that, but there isn't enough "meat". :) — Dsimic (talk | contribs) 17:41, 24 March 2014 (UTC)

Heck, just noticed that this section provides zero references. Please stop re-adding it until it provides more of the usable content. — Dsimic (talk | contribs) 02:21, 25 March 2014 (UTC)

Here's something that might be a good solution – I'll try to provide more content for that section, merging it with what you've already provided and restoring it all together. Hope you agree. — Dsimic (talk | contribs) 06:58, 25 March 2014 (UTC)

Sure, go ahead. User:ScotXW 10:48, 25 March 2014 (UTC)

Thank you, and sorry for the delay. I'll do that in the next day or two. — Dsimic (talk | contribs) 06:25, 27 March 2014 (UTC)

Once again, sorry for the delay; got a bit distracted. — Dsimic (talk | contribs) 05:21, 1 April 2014 (UTC)

No problem, I fixed it. User:ScotXW 10:31, 7 April 2014 (UTC)

Sorry, but I have to note that you're far away from being polite. Why did you have to write the following in your edit comment?

'in case you are not capable of "contributing"'

It hurts my feelings, while I bet you're not smarter or more knowledgeable than me. If you wanted to ping me about this, what was reasonable, this talk page was the place for that. — Dsimic (talk | contribs) 04:15, 8 April 2014 (UTC)

Let us both contribute text, and then work on that text. Let us not delete and remove stuff, if its not that bad. We already agreed it was fluffy. And I also told you, its WIP, i.e. I am on it. User:ScotXW 09:50, 9 April 2014 (UTC)

Ok, I'll add some more content and edit that section a bit, and you can take it from there. — Dsimic (talk | contribs) 16:49, 9 April 2014 (UTC)

Oculus Rift

Hi Scot, just wondering what this edit was about? Samwalton9 (talk) 13:00, 25 March 2014 (UTC)

Oh that. Oculus sent their "Joker" to make a funny presentation about the implications of VR... and I felt the urge to share the "take aways" from that particular presentation. I guess they can be removed again from the article. User:ScotXW 13:08, 25 March 2014 (UTC)

User page

Hi Scot, I suggest you have a read of WP:UPNOT; particularly regarding excessive unrelated content. Sam Walton (talk) 22:24, 27 March 2014 (UTC)

I just did Sam: "User pages are pages in the User and User talk namespaces, and are useful for organizing and aiding the work users do on Misplaced Pages". Anything else? User:ScotXW 10:20, 28 March 2014 (UTC)

Just thought the parts about "Writings, information, discussions, and activities not closely related to Misplaced Pages's goals" probably applied to the writings regarding your opinions on 'crippleware' located on your userpage. Sam Walton (talk) 17:07, 28 March 2014 (UTC)

I'd like to also point out that your "Misplaced Pages Deletion Heros" are a personal attack and don't help anyone. Sam Walton (talk) 18:15, 10 April 2014 (UTC)

How so? It helps in that patterns could be determined. Ye know, in case somebody targets the work of somebody particular, or a particular group of articles. Could be articles related to software in general, or articles related to races, language, you name it. Isn't there some tool for such cases? User:ScotXW 18:19, 10 April 2014 (UTC)

Nomination of GNOME Maps for deletion

A discussion is taking place as to whether the article GNOME Maps is suitable for inclusion in Misplaced Pages according to Misplaced Pages's policies and guidelines or whether it should be deleted.

The article will be discussed at Misplaced Pages:Articles for deletion/GNOME Maps until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article. QVVERTYVS (hm?) 17:05, 28 March 2014 (UTC)

Template talk:Linux

As a recent and major contributor to this template you may want to add something to this discussion on reducing the size of this template. - Ahunt (talk) 10:36, 31 March 2014 (UTC)

April 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Dialog (software) may have broken the syntax by modifying 2 ""s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

• ]