Farseerfc's Nest - linux//farseerfc.me/en/2016-07-31T03:52:00+09:00PacVis: visualize pacman local database2016-07-31T03:52:00+09:002016-07-31T03:52:00+09:00farseerfctag:farseerfc.me,2016-07-31:/en/pacvis.html
<div class="panel panel-default">
<div class="panel-heading">
PacVis</div>
<div class="panel-body">
<img alt="Demo of PacVis" class="img-responsive" src="//farseerfc.me/en/images/pacvis-first.png"/>
</div>
</div>
<div class="section" id="motivation-for-pacvis">
<h2><a class="toc-backref" href="#id2">Motivation for PacVis</a></h2>
<p>I must admit that I love Arch Linux, largely because Arch Linux made me feel
like I really <strong>own</strong> the whole system. In my Arch Linux system, I know clearly
every package I have installed and why I installed it. I can find which
package brings …</p></div>
<div class="panel panel-default">
<div class="panel-heading">
PacVis</div>
<div class="panel-body">
<img alt="Demo of PacVis" class="img-responsive" src="//farseerfc.me/en/images/pacvis-first.png"/>
</div>
</div>
<div class="section" id="motivation-for-pacvis">
<h2><a class="toc-backref" href="#id2">Motivation for PacVis</a></h2>
<p>I must admit that I love Arch Linux, largely because Arch Linux made me feel
like I really <strong>own</strong> the whole system. In my Arch Linux system, I know clearly
every package I have installed and why I installed it. I can find which
package brings in a give file. A Debian/Fedora/openSUSE user with enough experience
may achieve this with their favorite package manager too, but they must overcome
a much higher complexity with their distro's fine-grinding packaging strategy.
Usually they have 3 to 10 times more packages than Arch Linux on a
similar setup. And with regard to packaging system, they must work with much more
details than Arch's simple PKGBUILD based packaging.</p>
<p>Every user who successfully installed Arch Linux should have learned that, after
the initial installation, you will only get a minimum setup. The most important
step in the installation guide on ArchWiki is a command
<code class="code">
pactrap /mnt base</code>
, which will use <code class="code">
/mnt</code>
as the filesystem root
and call <code class="code">
pacman -S base</code>
inside that root to install the whole base
group. And that's basically all you will get after the install. The initial
system has nearly nothing. Everything you need will be installed afterwards,
manually by using <code class="code">
pacman</code>
. It is nothing unnecessary, only for
<strong>your</strong> own need.</p>
<p>But after using the system for a long time, there are unavoidably some packages
inside the system which are installed and used for awhile and abandoned.
They are like the old furnitures inside your house, taking space and covered by
dusts. We have <code class="code">
pacman -Qtd</code>
to help you find all orphan packages, namely
those <strong>installed as dependency for other packages once but not needed for now</strong>
, but for manually installed packages, we have no good tool but manually
checking them one by one.</p>
<p>So I was looking for a tool to help me understand the relations in my system.
In particular, I want a tool to help me do these things:</p>
<ol class="arabic simple">
<li>Find packages that I installed manually but not needed now</li>
<li>Find those large and space-consuming packages</li>
<li>Understand the relationships between packages</li>
</ol>
<div class="figure">
<img alt="Android System Architecture" class="img-responsive" src="//farseerfc.me/en/images/Android-System-Architecture.jpg"/>
<p class="caption"><a class="reference external" href="https://en.wikipedia.org/wiki/Android_(operating_system)">Android System Architecture</a></p>
</div>
<p>About the last thing "relations between packages", I once saw the diagram of
<a class="reference external" href="https://en.wikipedia.org/wiki/Architecture_of_OS_X">macOS Architecture</a>
and Android System Architecture, and I was impressed by the layered hierarchy
in these diagrams. I was wondering since then, <em>is it possible to draw a
similar layered architecture diagram for modern Linux desktop</em> ?
Or <em>will a Linux desktop be much different</em>?
I can find out hierarchy diagrams for Linux kernel or
Xorg graphic stack on Wikipedia or other sites, but I don't know such diagrams
for the whole distribution. And further I thought, can I <em>draw such diagram from
the dependency relationships between packages automatically</em>?</p>
</div>
<div class="section" id="predecessors-of-pacvis">
<h2><a class="toc-backref" href="#id3">Predecessors of PacVis</a></h2>
<p>Before working on PacVis, I have tried several similar tools. Some of them meet
some of my needs, but they all lack certain features that I considered important.
These tools became the prototype of PacVis, as they enlightened me of how PacVis
should be.</p>
<div class="section" id="pactree">
<h3><a class="toc-backref" href="#id4">pactree</a></h3>
<p>pactree started as an <a class="reference external" href="https://bbs.archlinux.org/viewtopic.php?id=51795">individual project</a>
, but now it is <a class="reference external" href="https://www.archlinux.org/pacman/pactree.8.html">part of pacman</a>.
From its manpage we can see that the output of pactree is a dependency tree
starting from a given package. By appending <code class="code">
--graph</code>
parameter, pactree
can also output a diagram in <a class="reference external" href="http://www.graphviz.org/">dot</a> format,
then we can render this diagram using dot command:</p>
<div class="panel panel-default">
<div class="panel-heading">
<code class="code">
pactree pacvis-git -d3 --graph | dot -Tpng >pacvis-pactree.png</code>
</div>
<div class="panel-body">
<img alt="pactree --graph" class="img-responsive" src="//farseerfc.me/en/images/pacvis-pactree.png"/>
</div>
</div>
<div class="highlight"><pre><span class="code-line"><span></span><span class="gp">$</span> pactree pacvis-git -d3</span>
<span class="code-line"><span class="go">pacvis-git</span></span>
<span class="code-line"><span class="go">├─python-tornado</span></span>
<span class="code-line"><span class="go">│ └─python</span></span>
<span class="code-line"><span class="go">│ ├─expat</span></span>
<span class="code-line"><span class="go">│ ├─bzip2</span></span>
<span class="code-line"><span class="go">│ ├─gdbm</span></span>
<span class="code-line"><span class="go">│ ├─openssl</span></span>
<span class="code-line"><span class="go">│ ├─libffi</span></span>
<span class="code-line"><span class="go">│ └─zlib</span></span>
<span class="code-line"><span class="go">├─pyalpm</span></span>
<span class="code-line"><span class="go">│ ├─python</span></span>
<span class="code-line"><span class="go">│ └─pacman</span></span>
<span class="code-line"><span class="go">│ ├─bash</span></span>
<span class="code-line"><span class="go">│ ├─glibc</span></span>
<span class="code-line"><span class="go">│ ├─libarchive</span></span>
<span class="code-line"><span class="go">│ ├─curl</span></span>
<span class="code-line"><span class="go">│ ├─gpgme</span></span>
<span class="code-line"><span class="go">│ ├─pacman-mirrorlist</span></span>
<span class="code-line"><span class="go">│ └─archlinux-keyring</span></span>
<span class="code-line"><span class="go">└─python-setuptools</span></span>
<span class="code-line"><span class="go"> └─python-packaging</span></span>
<span class="code-line"><span class="go"> ├─python-pyparsing</span></span>
<span class="code-line"><span class="go"> └─python-six</span></span>
<span class="code-line"><span class="gp"> $</span> pactree pacvis-git -d3 --graph <span class="p">|</span> dot -Tpng >pacvis-pactree.png</span>
</pre></div>
<p>From the rendered diagram we can see that, because some packages may share
common dependencies, the whole diagram is no longer a
<a class="reference external" href="https://en.wikipedia.org/wiki/Tree_structure">tree in graph theory</a> .
During the initial prototyping of PacVis, I tried to parse the output of pactree
and pacman using bash/python scripts, to draw a single diagram for the whole
system. However the rendered picture is so large that it takes hours for
dot to layout them, and the result is barely viewable in an image viewer or a
browser.</p>
<p>I need to say that there will be no PacVis if there is no pactree.
Even the pyalpm library that I used in PacVis is a python binding for alpm,
which is born during the rewrite of pactree in C language.</p>
</div>
<div class="section" id="pacgraph">
<h3><a class="toc-backref" href="#id5">pacgraph</a></h3>
<div class="panel panel-default">
<div class="panel-heading">
The output of pacgraph</div>
<div class="panel-body">
<img alt="pacgraph" class="img-responsive" src="//farseerfc.me/en/images/pacvis-pacgraph.png"/>
</div>
</div>
<p><a class="reference external" href="http://kmkeen.com/pacgraph/index.html">pacgraph</a> is developped by a
Arch Linux Trusted User <a class="reference external" href="http://kmkeen.com/">keenerd</a> . It is written
in Python, as is PacVis. Comparing with pactree, pacgraph is definitely more
suitable for my needs. It will draw a diagram for all the packages in the
system, using a clever layout algorithm that surpass the performance of
dot's layout.</p>
<p>The output of pacgraph is an artistic diagram with different font size of
package names showing their disk usage. By viewing pacgraph's output, we can
determine the overall system structure, e.g. whether the system is a desktop
system or a server. We can easily find large packages and consider remove them.</p>
<p>There's more. pacgraph provided an interactive GUI called pacgraph-tk, written
clearly in tk. You can zoom in to see details or zoom out to see the whole
graph in GUI, and you can highlight one package to see its relations to others.</p>
<p>And pacgraph support to render the dependencies of a selected group of packages,
not all, like pactree does.</p>
<p>But pacgraph does not meet all my needs. I want a diagram to show the
architecture of the system, but pacgraph don't differ
"the packages that this package depend on" and
"the packages that depends on this package". In other words, pacgraph draws a
<strong>undirected graph</strong>, but I want a <strong>directed graph</strong>, that reflects the
<strong>layered hierarchy of dependency relationship</strong>.</p>
</div>
</div>
<div class="section" id="so-here-is-pacvis">
<h2><a class="toc-backref" href="#id6">So here is PacVis</a></h2>
<div class="panel panel-default">
<div class="panel-heading">
PacVis on startup</div>
<div class="panel-body">
<img alt="PacVis on startup" class="img-responsive" src="//farseerfc.me/en/images/pacvis-second.png"/>
</div>
</div>
<p>With these predecessors, I started working on PacVis. The development takes
me 2 month, and largely break into 2 stages. In the first stage I wrote basic
logics and a prototype of the UI. In the second stage I applied the templates
from <a class="reference external" href="https://getmdl.io/">https://getmdl.io/</a> . Now finally it is usable for others.</p>
<p>So several days ago I made a PKGBUILD for pacvis on AUR:
<a class="reference external" href="https://aur.archlinux.org/packages/pacvis-git/">pacvis-git</a>.
Now it's fairly easy to run pacvis locally on a Arch Linux system.
You can use any aurhelper you familiar with, or build it directly from AUR:</p>
<div class="highlight"><pre><span class="code-line"><span></span><span class="go">~$ git clone aur@aur.archlinux.org:pacvis-git.git</span></span>
<span class="code-line"><span class="go">~$ cd pacvis-git</span></span>
<span class="code-line"><span class="go">~/pacvis-git$ makepkg -si</span></span>
<span class="code-line"><span class="go">~/pacvis-git$ pacvis</span></span>
<span class="code-line"><span class="go">Start PacVis at http://localhost:8888/</span></span>
</pre></div>
<p>Following the instruction, open <a class="reference external" href="http://localhost:8888/">http://localhost:8888/</a> in a browser then you can
see PacVis's result of your own system. As a demonstration you can also visit
PacVis on my Arch Linux server :
<a class="reference external" href="https://pacvis.farseerfc.me/">https://pacvis.farseerfc.me/</a> . It is showing a minimal server setup, that might
load and layout faster than a normal desktop system.</p>
<div class="panel panel-default">
<div class="panel-heading">
PacVis on Windows msys2</div>
<div class="panel-body">
<img alt="PacVis on Windows msys2" class="img-responsive" src="//farseerfc.me/en/images/pacvis-msys2.png"/>
</div>
</div>
<p>As a side note, pacvis only depends on pyalpm and tornado, so there should be
no problem running it on other pacman-based systems, including
<a class="reference external" href="https://msys2.github.io/">msys2 on Windows</a> (altough building a msys2
python-tornado may take some non-trival effort).</p>
</div>
<div class="section" id="the-legend-and-usage-of-pacvis">
<h2><a class="toc-backref" href="#id7">The legend and usage of PacVis</a></h2>
<p>PacVis resembles the UI of a map app such as Google Maps. You can use
wheel of mouse to zoom and drag to move, or pinch gestures on a touch screen.
There is a side panel on the right top corner and you can hide it when you don't
need it. There are some zoom buttons on the right bottom corner.</p>
<div class="figure">
<img alt="PacVis showing pacvis-git" class="img-responsive" src="//farseerfc.me/en/images/pacvis-pacvis-git.png"/>
<p class="caption">The dependencies of pacvis-git package</p>
</div>
<p>The whole diagram is made up of small circles and arrows in between circles.
A circle represent a package, while an arrow represents a dependency
relationship. If you zoom into details, you can see text under the circles
showing their package names. Hover on packages will also give you infos
about the package. You can select a package, and in the side panel there will be
more detailed infomation about that package.</p>
<p>The above picture is showing the dependencies of pacvis-git package itself.
It dependes on pyalpm, python-tornado and python-setuptools, while pyalpm
is in-turn depend on pacman.
A package in <span class="label label-primary">purple</span> means it is
installed manually, while a package in
<span class="label label-warning">orange</span> means it is installed
as a dependency for other packages. The color of arrows usually follow their
origin package's color.</p>
<p>Note that most arrows in the diagram are pointing bottom-up, this is because
PacVis will do a topology sort based on the dependencies of packages.
From the topology sort, PacVis assigned a <em>topology level</em> to each package,
e.g. pacvis-git has a topo-level of 39, its dependency pyalpm has a topo-level
of 38, and pacman is sat on the topo-level 37.
Layering packages with their topo-level is the main difference of PacVis with
pacgraph.</p>
<p>Besides manually zoom-in to look around, you can also use PacVis's search box
to locate a particular package by its name. And when you select a package,
the related package names will be shown in the Dep and Req-By tabs in the
sidebar. These package names are made as buttons so you can click them to
browse the whole dependency graph.</p>
<p>Let me describe some arguments related to the implementation:</p>
<div class="label label-info">
Max Level</div>
<p>This will limit the max topo-level that PacVis renders.
When there are too many packages, the layout algorithm will take a lot of time.
Limiting this is very useful during debug of PacVis.</p>
<div class="label label-info">
Max Required-By</div>
<p>This will limit the max required-by-relationship that PacVis renders.
If you play around in PacVis, you will soon find that most packages in the
system directly depends on glibc or gcc-libs. Rendering these <em>well-known</em>
dependency may result in a lot of long arrows, that reduce the readability of
the whole diagram. You can limit this to a lower number so that PacVis will
not render these <em>well-known</em> dependencies.</p>
</div>
<div class="section" id="some-facts-you-can-learn-from-pacvis">
<h2><a class="toc-backref" href="#id8">Some facts you can learn from PacVis</a></h2>
<div class="panel panel-default">
<div class="panel-heading">
A normal KDE desktop <a class="reference external" href="//farseerfc.me/en/images/pacvis-16384.png">Full image(17M)</a></div>
<div class="panel-body">
<img alt="A normal KDE desktop in PacVis" class="img-responsive" src="//farseerfc.me/en/images/pacvis-4096-anno.png"/>
</div>
</div>
<p>You may find many facts by playing around in PacVis. An example will be the
aforementioned "most packages depends on glibc".
Besides that, I will give some more examples below.</p>
<div class="section" id="dependency-hierachy">
<h3><a class="toc-backref" href="#id9">Dependency hierachy</a></h3>
<p>The packages in the system is clearly divided into several layers:</p>
<ul class="simple">
<li>glibc, etc. C runtime</li>
<li>Bash/Perl/Python etc. script languages</li>
<li>coreutils/gcc/binutils etc. core binary utilities</li>
<li>pacman/systemd etc. large system utilities</li>
<li>gtk{2,3}/qt{4,5} etc. GUI toolkit</li>
<li>chromium etc. GUI Applications</li>
<li>Plasma/Gnome etc. Desktop environments</li>
</ul>
<p>This largely meet my overall understanding, but some details are interesting to
me. For example, zsh dependes on gdbm which in-turn depends on bash, which means
that you can not get rid of bash even if you only use zsh.
For another example, python package (which is python3 in Arch Linux) and
python2 and pypy sit roughly on the same topo-level in the diagram.</p>
<div class="figure">
<img alt="zsh indirectly depends on bash because of gdbm" class="img-responsive" src="//farseerfc.me/en/images/pacvis-zsh-bash.png" style="width: 45%;"/>
<p class="caption">zsh indirectly depends on bash because of gdbm</p>
</div>
<p>However there are some facts beyond common knowledge, e.g.
qt5-base < qt4 < gtk2 < gtk3 with regard to topo-level.
Qt5 was split into several packages therefore it is understandable that
qt5-base is lower than qt4. The fact that gtk is more high level than qt
may beyond most expectations (including mine).</p>
</div>
<div class="section" id="circular-dependencies">
<h3><a class="toc-backref" href="#id10">Circular dependencies</a></h3>
<p>There are some packages that have circular dependencies in between.
An example will be freetype2 and harfbuzz. freetype2 is a library for font
rendering, and harfbuzz is a library to deal with OpenType font shapes.
They depend on each other. Another example is kio and kinit of KDE.
kio provides VFS-like and FUSE-like resource abstraction for KDE applications,
while kinit is in charge of initializing KDE desktop environment.</p>
<div class="figure">
<img alt="freetype2 harfbuzz" class="img-responsive" src="//farseerfc.me/en/images/pacvis-freetype2-harfbuzz.png" style="width: 45%;"/>
<p class="caption">Circular dependency between freetype2 and harfbuzz</p>
</div>
<p>Because of these circular dependencies, PacVis cannot simply apply topology sort
directly. Before that, PacVis will firstly find all circles in the dependency
graph to break these circles. It renders the relationship that will cause a
circle as red arrows in the diagram.</p>
</div>
<div class="section" id="some-packages-don-t-have-dependency-relationship">
<h3><a class="toc-backref" href="#id11">Some packages don't have dependency relationship</a></h3>
<div class="figure">
<img alt="PacVis Level 0" class="img-responsive" src="//farseerfc.me/en/images/pacvis-level0.png" style="width: 45%;"/>
<p class="caption">man-pages and licenses don't have dependencies</p>
</div>
<p>There are some packages that don't depend on others, and don't depended
by others. They are isolated in the whole diagram, e.g. man-pages and licenses.
These packages sit on the most top level of the diagram, with a topo-level of 0.
PacVis will render them as <span class="label label-info">blue</span>
squares specially.</p>
</div>
<div class="section" id="linux-the-kernel-is-unimportant-if-we-only-look-at-dependencies">
<h3><a class="toc-backref" href="#id12">Linux (the kernel) is unimportant, if we only look at dependencies</a></h3>
<p>All userspace program depend on glibc, which calls the kernel using well-defined
syscalls. As a result, if we only look at userspace dependencies, glibc and
other GNU components are the center of the GNU/Linux distribution, while
Linux the kernel is just located in a random place deeply blew the dependency
graph. On my demo server the Linux package is even located on the most bottom
level because it depends on mkinitcpio which in-turn depend on many components
in the system.</p>
</div>
<div class="section" id="pacman-qtd-cannot-find-orphan-packages-with-circle-dependency">
<h3><a class="toc-backref" href="#id13">pacman -Qtd cannot find orphan packages with circle dependency</a></h3>
<div class="figure">
<img alt="pacman -Qtd cannot find packages with circle dependency" class="img-responsive" src="//farseerfc.me/en/images/pacvis-circledeps-Qtd.png" style="width: 45%;"/>
<p class="caption">msys2 packages with circle dependency</p>
</div>
<p>I saw an archipelago of packages from mingw repo when testing PacVis on msys2.
To my surprise, they don't connected to any manually installed packages,
something strange as I routinely run <code class="code">
pacman -Qtd</code>
and remove the results on
all my systems. After zoomed in I found that they contained a circle dependency
which indicated <code class="code">
pacman -Qtd</code>
cannot find these orphan packages,
not like a GC algorithm.</p>
</div>
</div>
<div class="section" id="the-future-of-pacvis">
<h2><a class="toc-backref" href="#id14">The future of PacVis</a></h2>
<p>Currently PacVis is what I planned to make, with some features added during
the development. Some of these added features are related to the poor
performance of the layout algorithm (e.g. limiting the max level).</p>
<p>In the future I planned to add more features:</p>
<ol class="arabic simple">
<li>More reasonable behavior for optdeps. Currently PacVis draw optdeps but do
not consider it during the topology sort.</li>
<li>More reasonable <strong>dependency resolution</strong>. Sometimes the dependency is not
written directly as package names, instead they appear in <code class="code">
provides</code>
array in the metadata. Currently PacVis resolve all dependencies using
alpm directly, which will lose these information.</li>
<li>Currently PacVis did not consider the repository (core/extra/community) and
package group that a package belongs to. In the future PacVis may consider
these infomation to render a clearer hierarchy.</li>
<li>Currently PacVis cannot show only part of the packages. In the future we may
provide the ability to draw only a part of all the installed packages like
pactree/pacgraph does.</li>
</ol>
<p>If you want some features in PacVis, please
<a class="reference external" href="https://github.com/farseerfc/pacvis/issues">leave me an issue</a> .</p>
</div>
Jumping KDE5 Plasma Activities Button2014-12-09T01:54:00+09:002014-12-09T01:54:00+09:00farseerfctag:farseerfc.me,2014-12-09:/en/jumping-kde5-plasma-activities-button.html<!-- PELICAN_BEGIN_SUMMARY -->
<p>I found this when using activities under KDE5 today.
One can drag the activities button out of the edge of the screen,
then it will jump back and forth at the edge.
Here is a video:</p>
<!-- PELICAN_END_SUMMARY -->
<div class="well" style="padding: 0">
<div class="tab-content" id="youtubeku">
<div class="tab-pane fade active in" id="youtube_SSbf97jGSpI">
<div align="left" class="youtube embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" src="https://www.youtube.com/embed/SSbf97jGSpI"></iframe> </div>
</div>
<div class="tab-pane fade" id="youku_XODQ0NjM2MzQ4">
<div align="left" class="youku embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" height="498" src="https://player.youku.com/embed/XODQ0NjM2MzQ4" width="510"></iframe> </div>
</div>
</div>
<ul class="nav nav-tabs">
<li class="active"><a data-toggle="tab" href="#youtube_SSbf97jGSpI">Youtube</a></li>
<li><a data-toggle="tab" href="#youku_XODQ0NjM2MzQ4">Youku</a></li>
</ul>
</div>
<!-- PELICAN_BEGIN_SUMMARY -->
<p>Of course you can drag it back, so it is not a …</p><!-- PELICAN_BEGIN_SUMMARY -->
<p>I found this when using activities under KDE5 today.
One can drag the activities button out of the edge of the screen,
then it will jump back and forth at the edge.
Here is a video:</p>
<!-- PELICAN_END_SUMMARY -->
<div class="well" style="padding: 0">
<div class="tab-content" id="youtubeku">
<div class="tab-pane fade active in" id="youtube_SSbf97jGSpI">
<div align="left" class="youtube embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" src="https://www.youtube.com/embed/SSbf97jGSpI"></iframe> </div>
</div>
<div class="tab-pane fade" id="youku_XODQ0NjM2MzQ4">
<div align="left" class="youku embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" height="498" src="https://player.youku.com/embed/XODQ0NjM2MzQ4" width="510"></iframe> </div>
</div>
</div>
<ul class="nav nav-tabs">
<li class="active"><a data-toggle="tab" href="#youtube_SSbf97jGSpI">Youtube</a></li>
<li><a data-toggle="tab" href="#youku_XODQ0NjM2MzQ4">Youku</a></li>
</ul>
</div>
<!-- PELICAN_BEGIN_SUMMARY -->
<p>Of course you can drag it back, so it is not a serious problem.
It is just so cute that I had to note this.</p>
<p>By comparison, the jumping window in Gnome3 is far worse than this:</p>
<!-- PELICAN_END_SUMMARY -->
<div class="well" style="padding: 0">
<div class="tab-content" id="youtubeku">
<div class="tab-pane fade active in" id="youtube_TRQJdRHYwrw">
<div align="left" class="youtube embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" src="https://www.youtube.com/embed/TRQJdRHYwrw"></iframe> </div>
</div>
<div class="tab-pane fade" id="youku_XNjc4MjQ5NjE2">
<div align="left" class="youku embed-responsive embed-responsive-16by9"> <iframe allow="fullscreen" class="embed-responsive-item" frameborder="0" height="498" src="https://player.youku.com/embed/XNjc4MjQ5NjE2" width="510"></iframe> </div>
</div>
</div>
<ul class="nav nav-tabs">
<li class="active"><a data-toggle="tab" href="#youtube_TRQJdRHYwrw">Youtube</a></li>
<li><a data-toggle="tab" href="#youku_XNjc4MjQ5NjE2">Youku</a></li>
</ul>
</div>
<!-- PELICAN_BEGIN_SUMMARY -->
<p>BTW, I saw another cute translation error of mute screen in KDE5:</p>
<!-- PELICAN_END_SUMMARY -->
<blockquote class="twitter-tweet" lang="zh-tw"><p>KDE5のミュート画面の中国語翻訳、「静音」のはずだが「镜音」になっている。Vocaloidファンのネタだか、単なる入力ミスだか分からない。 <a href="http://t.co/ipyHjXMscR">pic.twitter.com/ipyHjXMscR</a></p>— Jiachen YANG (@farseerfc) <a href="https://twitter.com/farseerfc/status/541944351270518784">2014 12月 8日</a></blockquote>“…if we do this work … ” --Bill Gates2011-03-14T20:34:00+09:002011-03-14T20:34:00+09:00farseerfctag:farseerfc.me,2011-03-14:/en/if-we-do-this-work.html<p>Imported from
<a class="reference external" href="http://blog.renren.com/blog/230263946/716517729">renren</a></p>
<div class="section" id="if-we-do-this-work-and-the-result-is-that-linux-works-great-bill-gates">
<h2>“…if we do this work … and the result is that Linux works great …” --Bill Gates</h2>
<p>From: Bill Gates</p>
<p>’-- Sent: Sunday, January 24, 1999 8:41 AM</p>
<p>Jeff Westorinon; Ben Fathi ;</p>
<p>TO: Carl Stork (Exchange); Nathan Myhrvofd; Eric Rudder</p>
<p>Subject: ACPI extensions</p>
<p>One thing I find myself wondering …</p></div><p>Imported from
<a class="reference external" href="http://blog.renren.com/blog/230263946/716517729">renren</a></p>
<div class="section" id="if-we-do-this-work-and-the-result-is-that-linux-works-great-bill-gates">
<h2>“…if we do this work … and the result is that Linux works great …” --Bill Gates</h2>
<p>From: Bill Gates</p>
<p>’-- Sent: Sunday, January 24, 1999 8:41 AM</p>
<p>Jeff Westorinon; Ben Fathi ;</p>
<p>TO: Carl Stork (Exchange); Nathan Myhrvofd; Eric Rudder</p>
<p>Subject: ACPI extensions</p>
<p>One thing I find myself wondering about is whether we shouldn’t try and
make the "ACPI" extensions somehow Windows specific.</p>
<p>It seems unfortunate if we do this work and get our partners to do the
work and the result is that <strong>Linux works great without having to do the work</strong>.</p>
<p><strong>Maybe there is no way to avoid this problem but it does bother me.</strong></p>
<p>Maybe we could define the APIs so that they work well with NT and not
the others even if they are open.</p>
<p>Or maybe we could patent something relaled to this.</p>
<p>From:</p>
<p><a class="reference external" href="http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf">http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf</a></p>
<p>If this is the reason that Xen 4.0 is still not fully support ACPI 3.0, then f*ck
you Bill Gates!</p>
</div>