mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
joeren
commit
73adb9f2a5
@ -1,42 +0,0 @@
|
||||
Translating by H-mudcup
|
||||
Synfig Studio 1.0 — Open Source Animation Gets Serious
|
||||
================================================================================
|
||||
|
||||
|
||||
**A brand new version of the free, open-source 2D animation software Synfig Studio is now available to download. **
|
||||
|
||||
The first release of the cross-platform software in well over a year, Synfig Studio 1.0 builds on its claim of offering “industrial-strength solution for creating film-quality animation” with a suite of new and improved features.
|
||||
|
||||
Among them is an improved user interface that the project developers say is ‘easier’ and ‘more intuitive’ to use. The client adds a new **single-window mode** for tidy working and has been **reworked to use the latest GTK3 libraries**.
|
||||
|
||||
On the features front there are several notable changes, including the addition of a fully-featured bone system.
|
||||
|
||||
This **joint-and-pivot ‘skeleton’ framework** is well suited to 2D cut-out animation and should prove super efficient when coupled with the complex deformations new to this release, or used with Synfig’s popular ‘automatic interpolated keyframes’ (read: frame-to-frame morphing).
|
||||
|
||||
注：youtube视频
|
||||
<iframe width="750" height="422" frameborder="0" allowfullscreen="" src="https://www.youtube.com/embed/M8zW1qCq8ng?feature=oembed"></iframe>
|
||||
|
||||
New non-destructive cutout tools, friction effects and initial support for full frame-by-frame bitmap animation, may help unlock the creativity of open-source animators, as might the addition of a sound layer for syncing the animation timeline with a soundtrack!
|
||||
|
||||
### Download Synfig Studio 1.0 ###
|
||||
|
||||
Synfig Studio is not a tool suited for everyone, though the latest batch of improvements in this latest release should help persuade some animators to give the free animation software a try.
|
||||
|
||||
If you want to find out what open-source animation software is like for yourself, you can grab an installer for Ubuntu for the latest release direct from the project’s Sourceforge page using the links below.
|
||||
|
||||
- [Download Synfig 1.0 (64bit) .deb Installer][1]
|
||||
- [Download Synfig 1.0 (32bit) .deb Installer][2]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2015/04/synfig-studio-new-release-features
|
||||
|
||||
作者：[oey-Elijah Sneddon][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://plus.google.com/117485690627814051450/?rel=author
|
||||
[1]:http://sourceforge.net/projects/synfig/files/releases/1.0/linux/synfigstudio_1.0_amd64.deb/download
|
||||
[2]:http://sourceforge.net/projects/synfig/files/releases/1.0/linux/synfigstudio_1.0_x86.deb/download
|
||||
@ -1,446 +0,0 @@
|
||||
translating by wwy-hust
|
||||
|
||||
Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies
|
||||
=====================================================================
|
||||
|
||||
### Introduction
|
||||
|
||||
Intelligent content caching is one of the most effective ways to improve
|
||||
the experience for your site's visitors. Caching, or temporarily storing
|
||||
content from previous requests, is part of the core content delivery
|
||||
strategy implemented within the HTTP protocol. Components throughout the
|
||||
delivery path can all cache items to speed up subsequent requests,
|
||||
subject to the caching policies declared for the content.
|
||||
|
||||
In this guide, we will discuss some of the basic concepts of web content
|
||||
caching. This will mainly cover how to select caching policies to ensure
|
||||
that caches throughout the internet can correctly process your content.
|
||||
We will talk about the benefits that caching affords, the side effects
|
||||
to be aware of, and the different strategies to employ to provide the
|
||||
best mixture of performance and flexibility.
|
||||
|
||||
What Is Caching?
|
||||
----------------
|
||||
|
||||
Caching is the term for storing reusable responses in order to make
|
||||
subsequent requests faster. There are many different types of caching
|
||||
available, each of which has its own characteristics. Application caches
|
||||
and memory caches are both popular for their ability to speed up certain
|
||||
responses.
|
||||
|
||||
Web caching, the focus of this guide, is a different type of cache. Web
|
||||
caching is a core design feature of the HTTP protocol meant to minimize
|
||||
network traffic while improving the perceived responsiveness of the
|
||||
system as a whole. Caches are found at every level of a content's
|
||||
journey from the original server to the browser.
|
||||
|
||||
Web caching works by caching the HTTP responses for requests according
|
||||
to certain rules. Subsequent requests for cached content can then be
|
||||
fulfilled from a cache closer to the user instead of sending the request
|
||||
all the way back to the web server.
|
||||
|
||||
Benefits
|
||||
--------
|
||||
|
||||
Effective caching aids both content consumers and content providers.
|
||||
Some of the benefits that caching brings to content delivery are:
|
||||
|
||||
- **Decreased network costs**: Content can be cached at various points
|
||||
in the network path between the content consumer and content origin.
|
||||
When the content is cached closer to the consumer, requests will not
|
||||
cause much additional network activity beyond the cache.
|
||||
- **Improved responsiveness**: Caching enables content to be retrieved
|
||||
faster because an entire network round trip is not necessary. Caches
|
||||
maintained close to the user, like the browser cache, can make this
|
||||
retrieval nearly instantaneous.
|
||||
- **Increased performance on the same hardware**: For the server where
|
||||
the content originated, more performance can be squeezed from the
|
||||
same hardware by allowing aggressive caching. The content owner can
|
||||
leverage the powerful servers along the delivery path to take the
|
||||
brunt of certain content loads.
|
||||
- **Availability of content during network interruptions**: With
|
||||
certain policies, caching can be used to serve content to end users
|
||||
even when it may be unavailable for short periods of time from the
|
||||
origin servers.
|
||||
|
||||
Terminology
|
||||
-----------
|
||||
|
||||
When dealing with caching, there are a few terms that you are likely to
|
||||
come across that might be unfamiliar. Some of the more common ones are
|
||||
below:
|
||||
|
||||
- **Origin server**: The origin server is the original location of the
|
||||
content. If you are acting as the web server administrator, this is
|
||||
the machine that you control. It is responsible for serving any
|
||||
content that could not be retrieved from a cache along the request
|
||||
route and for setting the caching policy for all content.
|
||||
- **Cache hit ratio**: A cache's effectiveness is measured in terms of
|
||||
its cache hit ratio or hit rate. This is a ratio of the requests
|
||||
able to be retrieved from a cache to the total requests made. A high
|
||||
cache hit ratio means that a high percentage of the content was able
|
||||
to be retrieved from the cache. This is usually the desired outcome
|
||||
for most administrators.
|
||||
- **Freshness**: Freshness is a term used to describe whether an item
|
||||
within a cache is still considered a candidate to serve to a client.
|
||||
Content in a cache will only be used to respond if it is within the
|
||||
freshness time frame specified by the caching policy.
|
||||
- **Stale content**: Items in the cache expire according to the cache
|
||||
freshness settings in the caching policy. Expired content is
|
||||
"stale". In general, expired content cannot be used to respond to
|
||||
client requests. The origin server must be re-contacted to retrieve
|
||||
the new content or at least verify that the cached content is still
|
||||
accurate.
|
||||
- **Validation**: Stale items in the cache can be validated in order
|
||||
to refresh their expiration time. Validation involves checking in
|
||||
with the origin server to see if the cached content still represents
|
||||
the most recent version of item.
|
||||
- **Invalidation**: Invalidation is the process of removing content
|
||||
from the cache before its specified expiration date. This is
|
||||
necessary if the item has been changed on the origin server and
|
||||
having an outdated item in cache would cause significant issues for
|
||||
the client.
|
||||
|
||||
There are plenty of other caching terms, but the ones above should help
|
||||
you get started.
|
||||
|
||||
What Can be Cached?
|
||||
-------------------
|
||||
|
||||
Certain content lends itself more readily to caching than others. Some
|
||||
very cache-friendly content for most sites are:
|
||||
|
||||
- Logos and brand images
|
||||
- Non-rotating images in general (navigation icons, for example)
|
||||
- Style sheets
|
||||
- General Javascript files
|
||||
- Downloadable Content
|
||||
- Media Files
|
||||
|
||||
These tend to change infrequently, so they can benefit from being cached
|
||||
for longer periods of time.
|
||||
|
||||
Some items that you have to be careful in caching are:
|
||||
|
||||
- HTML pages
|
||||
- Rotating images
|
||||
- Frequently modified Javascript and CSS
|
||||
- Content requested with authentication cookies
|
||||
|
||||
Some items that should almost never be cached are:
|
||||
|
||||
- Assets related to sensitive data (banking info, etc.)
|
||||
- Content that is user-specific and frequently changed
|
||||
|
||||
In addition to the above general rules, it's possible to specify
|
||||
policies that allow you to cache different types of content
|
||||
appropriately. For instance, if authenticated users all see the same
|
||||
view of your site, it may be possible to cache that view anywhere. If
|
||||
authenticated users see a user-sensitive view of the site that will be
|
||||
valid for some time, you may tell the user's browser to cache, but tell
|
||||
any intermediary caches not to store the view.
|
||||
|
||||
Locations Where Web Content Is Cached
|
||||
-------------------------------------
|
||||
|
||||
Content can be cached at many different points throughout the delivery
|
||||
chain:
|
||||
|
||||
- **Browser cache**: Web browsers themselves maintain a small cache.
|
||||
Typically, the browser sets a policy that dictates the most
|
||||
important items to cache. This may be user-specific content or
|
||||
content deemed expensive to download and likely to be requested
|
||||
again.
|
||||
- **Intermediary caching proxies**: Any server in between the client
|
||||
and your infrastructure can cache certain content as desired. These
|
||||
caches may be maintained by ISPs or other independent parties.
|
||||
- **Reverse Cache**: Your server infrastructure can implement its own
|
||||
cache for backend services. This way, content can be served from the
|
||||
point-of-contact instead of hitting backend servers on each request.
|
||||
|
||||
Each of these locations can and often do cache items according to their
|
||||
own caching policies and the policies set at the content origin.
|
||||
|
||||
Caching Headers
|
||||
---------------
|
||||
|
||||
Caching policy is dependent upon two different factors. The caching
|
||||
entity itself gets to decide whether or not to cache acceptable content.
|
||||
It can decide to cache less than it is allowed to cache, but never more.
|
||||
|
||||
The majority of caching behavior is determined by the caching policy,
|
||||
which is set by the content owner. These policies are mainly articulated
|
||||
through the use of specific HTTP headers.
|
||||
|
||||
Through various iterations of the HTTP protocol, a few different
|
||||
cache-focused headers have arisen with varying levels of sophistication.
|
||||
The ones you probably still need to pay attention to are below:
|
||||
|
||||
- **`Expires`**: The `Expires` header is very straight-forward,
|
||||
although fairly limited in scope. Basically, it sets a time in the
|
||||
future when the content will expire. At this point, any requests for
|
||||
the same content will have to go back to the origin server. This
|
||||
header is probably best used only as a fall back.
|
||||
- **`Cache-Control`**: This is the more modern replacement for the
|
||||
`Expires` header. It is well supported and implements a much more
|
||||
flexible design. In almost all cases, this is preferable to
|
||||
`Expires`, but it may not hurt to set both values. We will discuss
|
||||
the specifics of the options you can set with `Cache-Control` a bit
|
||||
later.
|
||||
- **`Etag`**: The `Etag` header is used with cache validation. The
|
||||
origin can provide a unique `Etag` for an item when it initially
|
||||
serves the content. When a cache needs to validate the content it
|
||||
has on-hand upon expiration, it can send back the `Etag` it has for
|
||||
the content. The origin will either tell the cache that the content
|
||||
is the same, or send the updated content (with the new `Etag`).
|
||||
- **`Last-Modified`**: This header specifies the last time that the
|
||||
item was modified. This may be used as part of the validation
|
||||
strategy to ensure fresh content.
|
||||
- **`Content-Length`**: While not specifically involved in caching,
|
||||
the `Content-Length` header is important to set when defining
|
||||
caching policies. Certain software will refuse to cache content if
|
||||
it does not know in advanced the size of the content it will need to
|
||||
reserve space for.
|
||||
- **`Vary`**: A cache typically uses the requested host and the path
|
||||
to the resource as the key with which to store the cache item. The
|
||||
`Vary` header can be used to tell caches to pay attention to an
|
||||
additional header when deciding whether a request is for the same
|
||||
item. This is most commonly used to tell caches to key by the
|
||||
`Accept-Encoding` header as well, so that the cache will know to
|
||||
differentiate between compressed and uncompressed content.
|
||||
|
||||
### An Aside about the Vary Header
|
||||
|
||||
The `Vary` header provides you with the ability to store different
|
||||
versions of the same content at the expense of diluting the entries in
|
||||
the cache.
|
||||
|
||||
In the case of `Accept-Encoding`, setting the `Vary` header allows for a
|
||||
critical distinction to take place between compressed and uncompressed
|
||||
content. This is needed to correctly serve these items to browsers that
|
||||
cannot handle compressed content and is necessary in order to provide
|
||||
basic usability. One characteristic that tells you that
|
||||
`Accept-Encoding` may be a good candidate for `Vary` is that it only has
|
||||
two or three possible values.
|
||||
|
||||
Items like `User-Agent` might at first glance seem to be a good way to
|
||||
differentiate between mobile and desktop browsers to serve different
|
||||
versions of your site. However, since `User-Agent` strings are
|
||||
non-standard, the result will likely be many versions of the same
|
||||
content on intermediary caches, with a very low cache hit ratio. The
|
||||
`Vary` header should be used sparingly, especially if you do not have
|
||||
the ability to normalize the requests in intermediate caches that you
|
||||
control (which may be possible, for instance, if you leverage a content
|
||||
delivery network).
|
||||
|
||||
How Cache-Control Flags Impact Caching
|
||||
--------------------------------------
|
||||
|
||||
Above, we mentioned how the `Cache-Control` header is used for modern
|
||||
cache policy specification. A number of different policy instructions
|
||||
can be set using this header, with multiple instructions being separated
|
||||
by commas.
|
||||
|
||||
Some of the `Cache-Control` options you can use to dictate your
|
||||
content's caching policy are:
|
||||
|
||||
- **`no-cache`**: This instruction specifies that any cached content
|
||||
must be re-validated on each request before being served to a
|
||||
client. This, in effect, marks the content as stale immediately, but
|
||||
allows it to use revalidation techniques to avoid re-downloading the
|
||||
entire item again.
|
||||
- **`no-store`**: This instruction indicates that the content cannot
|
||||
be cached in any way. This is appropriate to set if the response
|
||||
represents sensitive data.
|
||||
- **`public`**: This marks the content as public, which means that it
|
||||
can be cached by the browser and any intermediate caches. For
|
||||
requests that utilized HTTP authentication, responses are marked
|
||||
`private` by default. This header overrides that setting.
|
||||
- **`private`**: This marks the content as `private`. Private content
|
||||
may be stored by the user's browser, but must *not* be cached by any
|
||||
intermediate parties. This is often used for user-specific data.
|
||||
- **`max-age`**: This setting configures the maximum age that the
|
||||
content may be cached before it must revalidate or re-download the
|
||||
content from the origin server. In essence, this replaces the
|
||||
`Expires` header for modern browsing and is the basis for
|
||||
determining a piece of content's freshness. This option takes its
|
||||
value in seconds with a maximum valid freshness time of one year
|
||||
(31536000 seconds).
|
||||
- **`s-maxage`**: This is very similar to the `max-age` setting, in
|
||||
that it indicates the amount of time that the content can be cached.
|
||||
The difference is that this option is applied only to intermediary
|
||||
caches. Combining this with the above allows for more flexible
|
||||
policy construction.
|
||||
- **`must-revalidate`**: This indicates that the freshness information
|
||||
indicated by `max-age`, `s-maxage` or the `Expires` header must be
|
||||
obeyed strictly. Stale content cannot be served under any
|
||||
circumstance. This prevents cached content from being used in case
|
||||
of network interruptions and similar scenarios.
|
||||
- **`proxy-revalidate`**: This operates the same as the above setting,
|
||||
but only applies to intermediary proxies. In this case, the user's
|
||||
browser can potentially be used to serve stale content in the event
|
||||
of a network interruption, but intermediate caches cannot be used
|
||||
for this purpose.
|
||||
- **`no-transform`**: This option tells caches that they are not
|
||||
allowed to modify the received content for performance reasons under
|
||||
any circumstances. This means, for instance, that the cache is not
|
||||
able to send compressed versions of content it did not receive from
|
||||
the origin server compressed and is not allowed.
|
||||
|
||||
These can be combined in different ways to achieve various caching
|
||||
behavior. Some mutually exclusive values are:
|
||||
|
||||
- `no-cache`, `no-store`, and the regular caching behavior indicated
|
||||
by absence of either
|
||||
- `public` and `private`
|
||||
|
||||
The `no-store` option supersedes the `no-cache` if both are present. For
|
||||
responses to unauthenticated requests, `public` is implied. For
|
||||
responses to authenticated requests, `private` is implied. These can be
|
||||
overridden by including the opposite option in the `Cache-Control`
|
||||
header.
|
||||
|
||||
Developing a Caching Strategy
|
||||
-----------------------------
|
||||
|
||||
In a perfect world, everything could be cached aggressively and your
|
||||
servers would only be contacted to validate content occasionally. This
|
||||
doesn't often happen in practice though, so you should try to set some
|
||||
sane caching policies that aim to balance between implementing long-term
|
||||
caching and responding to the demands of a changing site.
|
||||
|
||||
### Common Issues
|
||||
|
||||
There are many situations where caching cannot or should not be
|
||||
implemented due to how the content is produced (dynamically generated
|
||||
per user) or the nature of the content (sensitive banking information,
|
||||
for example). Another problem that many administrators face when setting
|
||||
up caching is the situation where older versions of your content are out
|
||||
in the wild, not yet stale, even though new versions have been
|
||||
published.
|
||||
|
||||
These are both frequently encountered issues that can have serious
|
||||
impacts on cache performance and the accuracy of content you are
|
||||
serving. However, we can mitigate these issues by developing caching
|
||||
policies that anticipate these problems.
|
||||
|
||||
### General Recommendations
|
||||
|
||||
While your situation will dictate the caching strategy you use, the
|
||||
following recommendations can help guide you towards some reasonable
|
||||
decisions.
|
||||
|
||||
There are certain steps that you can take to increase your cache hit
|
||||
ratio before worrying about the specific headers you use. Some ideas
|
||||
are:
|
||||
|
||||
- **Establish specific directories for images, css, and shared
|
||||
content**: Placing content into dedicated directories will allow you
|
||||
to easily refer to them from any page on your site.
|
||||
- **Use the same URL to refer to the same items**: Since caches key
|
||||
off of both the host and the path to the content requested, ensure
|
||||
that you refer to your content in the same way on all of your pages.
|
||||
The previous recommendation makes this significantly easier.
|
||||
- **Use CSS image sprites where possible**: CSS image sprites for
|
||||
items like icons and navigation decrease the number of round trips
|
||||
needed to render your site and allow your site to cache that single
|
||||
sprite for a long time.
|
||||
- **Host scripts and external resources locally where possible**: If
|
||||
you utilize javascript scripts and other external resources,
|
||||
consider hosting those resources on your own servers if the correct
|
||||
headers are not being provided upstream. Note that you will have to
|
||||
be aware of any updates made to the resource upstream so that you
|
||||
can update your local copy.
|
||||
- **Fingerprint cache items**: For static content like CSS and
|
||||
Javascript files, it may be appropriate to fingerprint each item.
|
||||
This means adding a unique identifier to the filename (often a hash
|
||||
of the file) so that if the resource is modified, the new resource
|
||||
name can be requested, causing the requests to correctly bypass the
|
||||
cache. There are a variety of tools that can assist in creating
|
||||
fingerprints and modifying the references to them within HTML
|
||||
documents.
|
||||
|
||||
In terms of selecting the correct headers for different items, the
|
||||
following can serve as a general reference:
|
||||
|
||||
- **Allow all caches to store generic assets**: Static content and
|
||||
content that is not user-specific can and should be cached at all
|
||||
points in the delivery chain. This will allow intermediary caches to
|
||||
respond with the content for multiple users.
|
||||
- **Allow browsers to cache user-specific assets**: For per-user
|
||||
content, it is often acceptable and useful to allow caching within
|
||||
the user's browser. While this content would not be appropriate to
|
||||
cache on any intermediary caching proxies, caching in the browser
|
||||
will allow for instant retrieval for users during subsequent visits.
|
||||
- **Make exceptions for essential time-sensitive content**: If you
|
||||
have content that is time-sensitive, make an exception to the above
|
||||
rules so that the out-dated content is not served in critical
|
||||
situations. For instance, if your site has a shopping cart, it
|
||||
should reflect the items in the cart immediately. Depending on the
|
||||
nature of the content, the `no-cache` or `no-store` options can be
|
||||
set in the `Cache-Control` header to achieve this.
|
||||
- **Always provide validators**: Validators allow stale content to be
|
||||
refreshed without having to download the entire resource again.
|
||||
Setting the `Etag` and the `Last-Modified` headers allow caches to
|
||||
validate their content and re-serve it if it has not been modified
|
||||
at the origin, further reducing load.
|
||||
- **Set long freshness times for supporting content**: In order to
|
||||
leverage caching effectively, elements that are requested as
|
||||
supporting content to fulfill a request should often have a long
|
||||
freshness setting. This is generally appropriate for items like
|
||||
images and CSS that are pulled in to render the HTML page requested
|
||||
by the user. Setting extended freshness times, combined with
|
||||
fingerprinting, allows caches to store these resources for long
|
||||
periods of time. If the assets change, the modified fingerprint will
|
||||
invalidate the cached item and will trigger a download of the new
|
||||
content. Until then, the supporting items can be cached far into the
|
||||
future.
|
||||
- **Set short freshness times for parent content**: In order to make
|
||||
the above scheme work, the containing item must have relatively
|
||||
short freshness times or may not be cached at all. This is typically
|
||||
the HTML page that calls in the other assisting content. The HTML
|
||||
itself will be downloaded frequently, allowing it to respond to
|
||||
changes rapidly. The supporting content can then be cached
|
||||
aggressively.
|
||||
|
||||
The key is to strike a balance that favors aggressive caching where
|
||||
possible while leaving opportunities to invalidate entries in the future
|
||||
when changes are made. Your site will likely have a combination of:
|
||||
|
||||
- Aggressively cached items
|
||||
- Cached items with a short freshness time and the ability to
|
||||
re-validate
|
||||
- Items that should not be cached at all
|
||||
|
||||
The goal is to move content into the first categories when possible
|
||||
while maintaining an acceptable level of accuracy.
|
||||
|
||||
Conclusion
|
||||
----------
|
||||
|
||||
Taking the time to ensure that your site has proper caching policies in
|
||||
place can have a significant impact on your site. Caching allows you to
|
||||
cut down on the bandwidth costs associated with serving the same content
|
||||
repeatedly. Your server will also be able to handle a greater amount of
|
||||
traffic with the same hardware. Perhaps most importantly, clients will
|
||||
have a faster experience on your site, which may lead them to return
|
||||
more frequently. While effective web caching is not a silver bullet,
|
||||
setting up appropriate caching policies can give you measurable gains
|
||||
with minimal work.
|
||||
|
||||
|
||||
---
|
||||
|
||||
作者: [Justin Ellingwood](https://www.digitalocean.com/community/users/jellingwood)
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
推荐：[royaso](https://github.com/royaso)
|
||||
|
||||
via: https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
@ -1,149 +0,0 @@
|
||||
FSSlc translating
|
||||
|
||||
Conky – The Ultimate X Based System Monitor Application
|
||||
================================================================================
|
||||
Conky is a system monitor application written in ‘C’ Programming Language and released under GNU General Public License and BSD License. It is available for Linux and BSD Operating System. The application is X (GUI) based that was originally forked from [Torsmo][1].
|
||||
|
||||
#### Features ####
|
||||
|
||||
- Simple User Interface
|
||||
- Higher Degree of configuration
|
||||
- It can show System stats using built-in objects (300+) as well as external scripts either on the desktop or in it’s own container.
|
||||
- Low on Resource Utilization
|
||||
- Shows system stats for a wide range of system variables which includes but not restricted to CPU, memory, swap, Temperature, Processes, Disk, Network, Battery, email, System messages, Music player, weather, breaking news, updates and blah..blah..blah
|
||||
- Available in Default installation of OS like CrunchBang Linux and Pinguy OS.
|
||||
|
||||
#### Lesser Known Facts about Conky ####
|
||||
|
||||
- The Name conky was derived from a Canadian Television Show.
|
||||
- It has already been ported to Nokia N900.
|
||||
- It is no more maintained officially.
|
||||
|
||||
### Conky Installation and Usage in Linux ###
|
||||
|
||||
Before we install conky, we need to install packages like lm-sensors, curl and hddtemp using following command.
|
||||
|
||||
# apt-get install lm-sensors curl hddtemp
|
||||
|
||||
Time to detect-sensors.
|
||||
|
||||
# sensors-detect
|
||||
|
||||
**Note**: Answer ‘Yes‘ when prompted!
|
||||
|
||||
Check all the detected sensors.
|
||||
|
||||
# sensors
|
||||
|
||||
#### Sample Output ####
|
||||
|
||||
acpitz-virtual-0
|
||||
Adapter: Virtual device
|
||||
temp1: +49.5°C (crit = +99.0°C)
|
||||
|
||||
coretemp-isa-0000
|
||||
Adapter: ISA adapter
|
||||
Physical id 0: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
Core 0: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
Core 1: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
|
||||
Conky can be installed from repo as well as, can be compiled from source.
|
||||
|
||||
# yum install conky [On RedHat systems]
|
||||
# apt-get install conky-all [On Debian systems]
|
||||
|
||||
**Note**: Before you install conky on Fedora/CentOS, you must have enabled [EPEL repository][2].
|
||||
|
||||
After conky has been installed, just issue following command to start it.
|
||||
|
||||
$ conky &
|
||||
|
||||
|
||||
Conky Monitor in Action
|
||||
|
||||
It will run conky in a popup like window. It uses the basic conky configuration file located at /etc/conky/conky.conf.
|
||||
|
||||
You may need to integrate conky with the desktop and won’t like a popup like window every-time. Here is what you need to do
|
||||
|
||||
Copy the configuration file /etc/conky/conky.conf to your home directory and rename it as ‘`.conkyrc`‘. The dot (.) at the beginning ensures that the configuration file is hidden.
|
||||
|
||||
$ cp /etc/conky/conky.conf /home/$USER/.conkyrc
|
||||
|
||||
Now restart conky to take new changes.
|
||||
|
||||
$ killall -SIGUSR1 conky
|
||||
|
||||
|
||||
Conky Monitor Window
|
||||
|
||||
You may edit the conky configuration file located in your home dircetory. The configuration file is very easy to understand.
|
||||
|
||||
Here is a sample configuration of conky.
|
||||
|
||||
|
||||
Conky Configuration
|
||||
|
||||
From the above window you can modify color, borders, size, scale, background, alignment and several other properties. By setting different alignments to different conky window, we can run more than one conky script at a time.
|
||||
|
||||
**Using script other than the default for conky and where to find it?**
|
||||
|
||||
You may write your own conky script or use one that is available over Internet. We don’t suggest you to use any script you find on the web which can be potentially dangerous unless you know what you are doing. However a few famous threads and pages have conky script that you can trust as mentioned below.
|
||||
|
||||
- [http://ubuntuforums.org/showthread.php?t=281865][3]
|
||||
- [http://conky.sourceforge.net/screenshots.html][4]
|
||||
|
||||
At the above url, you will find every screenshot has a hyperlink, which will redirects to script file.
|
||||
|
||||
#### Testing Conky Script ####
|
||||
|
||||
Here I will be running a third party written conky-script on my Debian Jessie Machine, to test.
|
||||
|
||||
$ wget https://github.com/alexbel/conky/archive/master.zip
|
||||
$ unzip master.zip
|
||||
|
||||
Change current working directory to just extracted directory.
|
||||
|
||||
$ cd conky-master
|
||||
|
||||
Rename the secrets.yml.example to secrets.yml.
|
||||
|
||||
$ mv secrets.yml.example secrets.yml
|
||||
|
||||
Install Ruby before you could run this (ruby) script.
|
||||
|
||||
$ sudo apt-get install ruby
|
||||
$ ruby starter.rb
|
||||
|
||||
|
||||
Conky Fancy Look
|
||||
|
||||
**Note**: This script can be modified to show your current weather, temperature, etc.
|
||||
|
||||
If you want to start conky at boot, add the below one liner to startup Applications.
|
||||
|
||||
conky --pause 10
|
||||
save and exit.
|
||||
|
||||
And Finally…such a lightweight and useful GUI eye candy like package is not in active stage and is not maintained officially anymore. The last stable release was conky 1.9.0 released on May 03, 2012. A thread on Ubuntu forum has gone over 2k pages of users sharing configuration. (link to forum : [http://ubuntuforums.org/showthread.php?t=281865/][5])
|
||||
|
||||
- [Conky Homepage][6]
|
||||
|
||||
That’s all for now. Keep connected. Keep commenting. Share your thoughts and configuration in comments below.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/install-conky-in-ubuntu-debian-fedora/
|
||||
|
||||
作者：[Avishek Kumar][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/avishek/
|
||||
[1]:http://torsmo.sourceforge.net/
|
||||
[2]:http://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/
|
||||
[3]:http://ubuntuforums.org/showthread.php?t=281865
|
||||
[4]:http://conky.sourceforge.net/screenshots.html
|
||||
[5]:http://ubuntuforums.org/showthread.php?t=281865/
|
||||
[6]:http://conky.sourceforge.net/
|
||||
@ -1,3 +1,5 @@
|
||||
FSSlc translating
|
||||
|
||||
Install uGet Download Manager 2.0 in Debian, Ubuntu, Linux Mint and Fedora
|
||||
================================================================================
|
||||
After a long development period, which includes more than 11 developement releases, finally uGet project team pleased to announce the immediate availability of the latest stable version of uGet 2.0. The latest version includes numerous attractive features, such as a new setting dialog, improved BitTorrent and Metalink support added in the aria2 plugin, as well as better support for uGet RSS messages in the banner, other features include:
|
||||
@ -131,4 +133,4 @@ via: http://www.tecmint.com/install-uget-download-manager-in-linux/
|
||||
[2]:http://ugetdm.com/downloads
|
||||
[3]:http://www.tecmint.com/install-aria2-a-multi-protocol-command-line-download-manager-in-rhel-centos-fedora/
|
||||
[4]:http://ugetdm.com/downloads-aria2
|
||||
[5]:http://ugetdm.com/downloads
|
||||
[5]:http://ugetdm.com/downloads
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
translating by wwy-hust
|
||||
|
||||
Install Linux-Dash (Web Based Monitoring tool) on Ubntu 14.10
|
||||
================================================================================
|
||||
|
||||
@ -0,0 +1,43 @@
|
||||
Translating by H-mudcup
|
||||
|
||||
Synfig Studio 1.0 —— 开源动画动真格的了
|
||||
================================================================================
|
||||
|
||||
|
||||
**现在可以下载 Synfig Studio 这个自由、开源的2D动画软件的全新版本了。 **
|
||||
|
||||
在第一次发行这个跨平台的软件一年以后，Synfig Studio 1.0 带着一套全新改和改进过的功能，实现它所承诺的“创造电影级别的动画的产业级解决方案”。
|
||||
|
||||
在众多功能之上的是一个改进过的用户界面，据工程开发者说那是个用起来‘更简单’、‘更直观’的界面。客户端添加了新的**单窗口模式**，让界面更整洁，而且**为了使用最新的 GTK3 库而被重新制作**。
|
||||
|
||||
在功能方面有几个值得注意的变化，包括新加的全功能骨骼系统。
|
||||
|
||||
这套**关节和转轴的‘骨骼’构架**非常适合2D剪纸动画，再配上这个版本新加的复杂的变形控制系统或是 Synfig 受欢迎的‘关键帧自动插入’（阅读：画面与画面间的变形）应该会变得非常有效率的。
|
||||
|
||||
注：youtube视频
|
||||
<iframe width="750" height="422" frameborder="0" allowfullscreen="" src="https://www.youtube.com/embed/M8zW1qCq8ng?feature=oembed"></iframe>
|
||||
|
||||
新的无损剪切工具，摩擦力效果和对逐帧位图动画的支持，可能会有助于释放开源动画师们的创造力，更别说新加的用于同步动画的时间线和声音的声效层！
|
||||
|
||||
### 下载 Synfig Studio 1.0 ###
|
||||
|
||||
Synfig Studio 并不是任何人都能用的工具套件，这最新发行版的最新一批改进应该能吸引一些动画制作者试一试这个软件。
|
||||
|
||||
If you want to find out what open-source animation software is like for yourself, you can grab an installer for Ubuntu for the latest release direct from the project’s page using the links below. 如果你想看看开源动画制作软件是什么样的，你可以通过下面的链接直接从工程的 Sourceforge 页下载一个适用于 Ubuntu 的最新版本的安装器。
|
||||
|
||||
- [Download Synfig 1.0 (64bit) .deb Installer][1]
|
||||
- [Download Synfig 1.0 (32bit) .deb Installer][2]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2015/04/synfig-studio-new-release-features
|
||||
|
||||
作者：[oey-Elijah Sneddon][a]
|
||||
译者：[H-mudcup](https://github.com/H-mudcup)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://plus.google.com/117485690627814051450/?rel=author
|
||||
[1]:http://sourceforge.net/projects/synfig/files/releases/1.0/linux/synfigstudio_1.0_amd64.deb/download
|
||||
[2]:http://sourceforge.net/projects/synfig/files/releases/1.0/linux/synfigstudio_1.0_x86.deb/download
|
||||
@ -0,0 +1,198 @@
|
||||
Web缓存基础：术语、HTTP报头和缓存策略
|
||||
=====================================================================
|
||||
|
||||
### 简介
|
||||
|
||||
对于您的站点的访问者来说，智能化的内容缓存是提高用户体验最有效的方式之一。缓存，或者对之前请求的临时存储，是HTTP协议实现中最核心的内容分发策略之一。分发路径中的组件均可以缓存内容来加速后续的请求，这受制于对该内容所声明的缓存策略。
|
||||
|
||||
在这份指南中，我们将讨论一些Web内容缓存的基本概念。这主要包括如何选择缓存策略以保证互联网范围内的缓存能够正确的处理您的内容。我们将谈一谈缓存带来的好处、副作用以及不同的策略能带来的性能和灵活性的最大结合。
|
||||
|
||||
什么是缓存？
|
||||
------------
|
||||
|
||||
缓存是存储可重用资源以便加快后续请求的术语。有许多不同类型的缓存，每种都有其自身的特点，应用程序缓存和内存缓存由于其对特定回复的加速，都很常用。
|
||||
|
||||
Web缓存，这份指南的中心，是一种不同类型的缓存。Web缓存是HTTP协议的一个核心特性，它能最小化网络流量，并且提升用户感知到的整个系统的响应速度。内容从服务器到浏览器的传输过程中，每个层面都可以找到缓存的身影。
|
||||
|
||||
Web缓存根据特定的规则缓存相应HTTP请求的回复。对于缓存内容的后续请求便可以直接由缓存满足而不是重新发送请求到Web服务器。
|
||||
|
||||
好处
|
||||
----
|
||||
|
||||
有效的缓存技术不仅帮助用户，还帮助内容的提供者。缓存对内容分发带来的好处有：
|
||||
|
||||
- **减少网络开销**：内容可以在从内容提供者到内容消费者网络路径之间的许多不同的地方被缓存。当内容在距离内容消费者更近的地方被缓存时，由于缓存的存在，请求将不会消耗额外的网络资源。
|
||||
|
||||
- **加快响应速度**：由于整个网络往返变得并不是必需的，缓存可以使内容的获得变得更快。缓存在距用户更近的地方被维护，例如浏览器缓存，使得内容的获取几乎是瞬时的。
|
||||
|
||||
- **在同样的硬件上提高速度**：对于保存原始内容的服务器来说，更多的性能可以通过允许激进的缓存策略从硬件上压榨出来。内容拥有者们可以利用交付路径上强大的服务器来应对某个内容负载的冲击。
|
||||
|
||||
- **网络中断时内容依旧可用**：使用某种策略，缓存可以保证在原始服务器变得不可用时，相应的内容对用户依旧可用。
|
||||
|
||||
术语
|
||||
----
|
||||
|
||||
在面对缓存时，您可能对一些经常遇到的术语可能不太熟悉。一些常见的术语如下：
|
||||
|
||||
- **原始服务器**：原始服务器是内容的原始存放地点。如果您是Web服务器管理员，它就是您所管理的机器。它负责为任何不能从缓存中得到的内容进行回复，并且负责设置所有内容的缓存策略。
|
||||
|
||||
- **缓存命中率**：一个缓存的有效性依照缓存的命中率进行度量。它是可以从缓存中得到数据的请求数与所有请求数的比率。缓存命中率高意味着有很高比例的数据可以从缓存中获得。这通常是大多数管理员想要的结果。
|
||||
|
||||
- **新鲜度**：新鲜度用来描述一个缓存中的项目是否依旧适合返回给客户端。缓存中的内容只有在由缓存策略指定的新鲜期内才会被返回。
|
||||
|
||||
- **过期内容**：缓存中根据缓存策略的新鲜期设置已过期的内容。过期的内容被标记为“陈旧”。通常，过期内容不能用于回复客户端的请求。必须重新从原始服务器请求新的内容或者至少验证缓存的内容是否仍然准确。
|
||||
|
||||
- **校验**：缓存中的过期内容可以被验证有效以便刷新过期时间。验证过程包括联系原始服务器以检查缓存的数据是否依旧代表了最近的版本。
|
||||
|
||||
- **失效**：失效是依据过期日期从缓存中移除内容的过程。当内容在原始服务器上已被改变并且缓存中过期的内容会导致客户端的签名问题时这个步骤是必须的。
|
||||
|
||||
还有许多其他的缓存术语，不过上面的这些应该能帮助您开始。
|
||||
|
||||
什么能被缓存？
|
||||
--------------
|
||||
|
||||
某些特定的内容比其他内容更容易被缓存。对大多数站点来说，一些缓存友好的内容如下：
|
||||
|
||||
- Logo和商标图像
|
||||
- 通用的非旋转的图像（例如，导航图标）
|
||||
- 样式表
|
||||
- 通用Javascript文件
|
||||
- 可下载的内容
|
||||
- 媒体文件
|
||||
|
||||
这些文件更倾向于不经常改变，所以长时间的对他们进行缓存能获得好处。
|
||||
|
||||
一些项目在缓存中必须加以注意：
|
||||
|
||||
- HTML页面
|
||||
- 旋转的图像
|
||||
- 经常修改的Javascript和CSS文件
|
||||
- 经过登陆的cookies访问的内容
|
||||
|
||||
一些内容从来不应该被缓存：
|
||||
|
||||
- 与敏感信息相关的资源（银行数据，等）
|
||||
- 用户相关且经常更改的数据
|
||||
|
||||
除上面的通用规则外，通常您需要指定一些规则以便于更好地缓存不同种类的内容。例如，如果登陆的用户都看到的是同样的网站视图，就应该在任何地方缓存这个页面。如果登陆的用户会在一段时间内看到站点中用户敏感的视图，您应该让用户的浏览器缓存该数据而不应让任何中介节点缓存该视图。
|
||||
|
||||
Web内容缓存的位置
|
||||
-----------------
|
||||
|
||||
Web内容会在整个分发路径中的许多不同的地点被缓存：
|
||||
|
||||
- **浏览器缓存**：Web浏览器自身会维护一个小型缓存。典型地，浏览器使用一种策略指示缓存最重要的内容。这可能是用户相关的内容或可能会再次请求且下载代价较高。
|
||||
- **中间缓存代理**：任何在客户端和您的基础架构之间的服务器都可以按期望缓存一些内容。这些缓存可能由ISP（网络服务提供者）或者其他独立组织提供。
|
||||
- **反向缓存**：您的服务器基础架构可以为后端的服务实现自己的缓存。如果实现了缓存，那么便可以在请求接触点返回相应的内容而不用每次请求都使用后端服务。
|
||||
|
||||
上面的这些位置通常都可以根据它们自身的缓存策略和内容源点的缓存策略缓存一些相应的内容。
|
||||
|
||||
缓存头部
|
||||
--------
|
||||
|
||||
缓存策略依赖于两个不同的因素。缓存实体本身需要决定是否应该缓存可接受的内容。它可以只缓存部分可以缓存的内容，但不能缓存超过限制的内容。
|
||||
|
||||
缓存行为主要由缓存策略决定，而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来清晰地表达。
|
||||
|
||||
经过不同HTTP协议的迭代，一些不同的聚焦于缓存的头部出现了，它们的复杂度各不相同。下面列出了那些你也许应该注意的：
|
||||
|
||||
- **`Expires`**：尽管使用范围相当有限，但`Expires`头部是非常简洁明了的。通常它设置一个未来的时间，内容会在此时间过期。这时，任何对同样内容的请求都应该回到原始服务器处。这个头部或许仅仅最适合回退模式（fall back）。
|
||||
- **`Cache-Control`**：这是`Expires`的一个更加现代化的替换物。它已被很好的支持，且拥有更加灵活的实现。在大多数案例中，它比`Expires`更好，但同时设置两者的值也无妨。稍后我们将讨论您可以设置的`Cache-Control`的详细选项。
|
||||
- **`ETag`**：`ETag`用于缓存验证。源服务器可以在首次服务一个内容时为该内容提供一个独特的`ETag`。当一个缓存需要验证这个内容是否即将过期，他会将相应的`ETag`发送回服务器。源服务器或者告诉缓存内容是一致的，或者发送更新后的内容（带着新的`ETag`）。
|
||||
- **`Last-Modified`**：这个头部指明了相应的内容最后一次被修改的时间。它可能会作为保证内容新鲜度的验证策略的一部分被使用。
|
||||
- **`Content-Length`**：尽管并没有明确的在缓存中被涉及，`Content-Length`头部在设置缓存策略时很重要。某些软件如果不提前获知内容的大小以留出足够空间，则会拒绝缓存该内容。
|
||||
- **`Vary`**：缓存系统通常使用请求的主机和路径作为存储该资源的键。`Vary`头部可以被用来在决定一个请求是否是请求同样的内容时提醒缓存系统注意另一个附加的头部。它通常被用来告诉缓存系统同样的使用`Accept-Encoding`头部作为键，因此缓存系统能够区分压缩和未压缩的内容。
|
||||
|
||||
### Vary头部的隐语
|
||||
|
||||
`Vary`头部提供给您存储同一个内容的不同版本的能力。代价是稀释了缓存的入口。
|
||||
|
||||
在`Accept-Encoding`的案例中，设置`Vary`头部允许压缩和未压缩的内容拥有决定性的区别。这在服务某些不能处理压缩数据的浏览器时很重要，它可以保证基本的使用。`Accept-Encoding`是`Vary`的不错的候选值是因为它只有两到三个可选的值。
|
||||
|
||||
`User-Agent`这样的头部可能一开始看上去是区分移动浏览器和桌面浏览器以便您的站点提供差异化的服务的好主意。但`User-Agent`字符串是非标准的，结果将会造成在中间缓存中对同一内容的许多不同版本的缓存，这会导致缓存命中率的降低。`Vary`头部应该被保守地使用，尤其是您不具备在您控制的中间混存（例如，您控制着内容分发网络）中使请求标准化的能力。
|
||||
|
||||
缓存控制标志怎样影响缓存
|
||||
------------------------
|
||||
|
||||
上面我们提到了`Cache-Control`头部如何被用与现代缓存策略标准。许多不同的缓存指令能够通过这个头部被设定，多个不同的指令通过逗号进行分分隔。
|
||||
|
||||
一些您可以使用的指示内容缓存策略的`Cache-Control`的选项如下：
|
||||
|
||||
- **`no-cache`**：这个指令指示所有缓存的内容在新的请求到达时必须先重新验证，再发送给客户端。这条指令实际将内容立刻标记为过期的，但允许它们被验证技术重新验证以避免重新下载整个内容。
|
||||
- **`no-store`**：这条指令指示缓存的内容不能以任何方式被缓存。它适合在回复敏感信息时设置。
|
||||
- **`public`**：它将内容标记为公有的，这意味着它能被浏览器和其他任何中间节点缓存。通常，对于使用了HTTP验证的请求，其回复被默认标记为`private`。`public`标记将会覆盖这个设置。
|
||||
- **`private`**：它将内容标记为私有的。私有数据可以被用户的浏览器缓存，但*不能*被任何中间节点缓存。它通常用于用户相关的数据。
|
||||
- **`max-age`**：这个设置指示了缓存内容的最大生存期，它在最大生存期后必须在源服务器处被验证或被重新下载。在现代浏览器中这个选项大体上取代了`Expires`头部，浏览器也将其作为决定内容的新鲜度的基础。这个选项的值以秒为单位表示，最大可以表示一年的新鲜期（31536000秒）。
|
||||
- **`s-maxage`**：这个选项非常类似于`max-age`，它指明了内容能够被缓存的时间。区别是这个选项只在中间节点的缓存中有效。结合这两个选项可以构建更加灵活的缓存策略。
|
||||
- **`must-revalidate`**：它指明了由`max-age`、`s-maxage`或`Expires`头部指明的新鲜度信息必须被严格的遵守。它避免了缓存的数据在网络中断等类似的场景中被使用。
|
||||
- **`proxy-revalidate`**：它和上面的选项有着一样的作用，但只应用于中间的代理节点。在这种情况下，用户的浏览器可以在网络中断时使用过期内容，但中间的缓存内容不能用于此目的。
|
||||
- **`no-transform`**：这个选项告诉缓存在任何情况下都不能因为性能的原因修改接收到的内容。这意味着，缓存不允许压缩接收到的内容（没有从原始服务器处接收过压缩版本的该内容）并发送。
|
||||
|
||||
这些选项能够以不同的方式结合以获得不同的缓存行为。一些互斥的值如下：
|
||||
|
||||
- `no-cache`，`no-store`以及由其他前面未提到的选项指明的常用的缓存行为
|
||||
- `public`和`private`
|
||||
|
||||
如果`no-store`和`no-cache`都被设置，那么`no-store`会取代`no-cache`。对于非授权的请求的回复，`public`是隐含的设置。对于授权的请求的回复，`private`选项是隐含的。他们可以通过在`Cache-Control`头部中指明相应的相反的选项以覆盖。
|
||||
|
||||
开发一种缓存策略
|
||||
----------------
|
||||
|
||||
在理想情况下，任何内容都可以被激进的缓存，而您的服务器只需要偶尔的提供一些验证内容即可。但这在现实中很少发生，因此您应该尝试设置一些明智的缓存策略，以在长期缓存和站点改变的需求间达到平衡。
|
||||
|
||||
### 常见问题
|
||||
|
||||
在许多情况中，由于内容被产生的方式（根据每个用户动态的产生）或者内容的特性（例如银行的敏感数据），这些内容不应该被缓存。另一些许多管理员在设置缓存时可能面对的问题是外部缓存的数据未过期，但新版本的数据已经产生。
|
||||
|
||||
这些都是经常遇到的问题，它们会影响缓存的性能和您提供的数据的准确性。然而，我们可以通过开发提前预见这些问题的缓存策略来缓和这些问题。
|
||||
|
||||
### 一般性建议
|
||||
|
||||
尽管您的实际情况会指导您选择的缓存策略，但是下面的建议能帮助您获得一些合理的决定。
|
||||
|
||||
在您担心使用哪一个特定的头部之前，有一些特定的步骤可以帮助您提高您的缓存命中率。一些建议如下：
|
||||
|
||||
- **为图像、CSS和共享的内容建立特定的文件夹**：将内容放到特定的文件夹内使得您可以方便的从您的站点中的任何页面引用这些内容。
|
||||
- **使用同样的URL来表示同样的内容**：由于缓存使用内容请求中的主机名和路径作为键，因此应保证您的所有页面中的该内容的引用方式相同，前一个建议能让这点更加容易做到。
|
||||
- **尽可能使用CSS图像精灵**：对于像图标和导航等内容，使用CSS图像精灵能够减少渲染您页面所需要往返，并且允许对精灵缓存很长一段时间。
|
||||
- **尽可能将主机脚本和外部资源本地化**：如果您使用Javascript脚本和其他外部资源，如果上游没有提供合适的缓存头部，那么您应考虑将这些内容放在您自己的服务器上。您应该注意上游的任何更新，以便更新本地的拷贝。
|
||||
- **对缓存内容收集文件摘要**：静态的内容比如CSS和Javascript文件等通常比较适合收集文件摘要。这意味着为文件名增加一个独特的标志符（通常是这个文件的哈希值）可以在文件修改后绕开缓存保证新的内容被重新获取。有很多工具可以帮助您创建文件摘要并且修改HTML文档中的引用。
|
||||
|
||||
对于不同的文件正确地选择不同的头部这件事，下面的内容可以作为一般性的参考：
|
||||
|
||||
- **允许所有的缓存存储一般内容**：静态内容以及非用户相关的内容应该在分发链的所有节点被缓存。这使得中间节点可以将该内容回复给多个用户。
|
||||
- **允许浏览器缓存用户相关的内容**：对于每个用户的数据，通常在用户自己的浏览器中缓存是可以被接受且有益的。缓存在用户自身的浏览器能够使得用户在接下来的浏览中能够瞬时读取，但这些内容不适合在任何中间代理节点缓存。
|
||||
- **将时间敏感的内容作为特例**：如果您的数据是时间敏感的，那么相对上面两条参考，应该将这些数据作为特例，以保证过期的数据不会在关键的情况下被使用。例如，您的站点有一个购物车，它应该立刻反应购物车里面的物品。依据内容的特点，可以在`Cache-Control`头部中使用`no-cache`或`no-store`选项。
|
||||
- **总是提供验证器**：验证器使得过期的内容可以无需重新下载而得到刷新。设置`ETag`和`Last-Modified`头部将允许缓存向原始服务器验证内容，并在内容未修改时刷新该内容新鲜度以减少负载。
|
||||
- **对于支持的内容设置长的新鲜期**：为了更加有效的利用缓存，一些作为支持性的内容应该被设置较长的新鲜期。这通常比较适合图像和CSS等由用户请求用来渲染HTML页面的内容。和文件摘要一起，设置延长的新鲜期将允许缓存长时间的存储这些资源。如果资源发生改变，修改的文件摘要将会使缓存的数据无效并触发对新的内容的下载。那时，新的支持的内容会继续被缓存。
|
||||
- **对父内容设置短的新鲜期**：为了使得前面的模式正常工作，容器类的内容应该相应的设置短的新鲜期，或者设置不全部被缓存。这通常是在其他协助内容中使用的HTML页面。这个HTML页面将会被频繁的下载，使得它能快速的响应改变。支持性的内容因此可以被激进的缓存。
|
||||
|
||||
关键之处便在于达到平衡，一方面可以激进的进行缓存，另一方面为未来保留改变整个内容的机会。当改变发生时，您的站点应该同时具有：
|
||||
|
||||
- 激进地缓存的内容
|
||||
- 拥有短的新鲜期的缓存内容，可以被重新验证
|
||||
- 完全不被缓存的内容
|
||||
|
||||
这样做的目的便是将内容尽可能的移动到第一个分类（激进的缓存）中的同时，维持可以接受的缓存命中率。
|
||||
|
||||
结论
|
||||
----
|
||||
|
||||
花时间确保您的站点使用了合适的缓存策略将对您的站点产生重要的影响。缓存使得您可以在保证服务同样内容的同时减少带宽的使用。您的服务器因此可以靠同样的硬件处理更多的流量。或许更重要的是，客户们能在您的网站中获得更快的体验，这会使得他们更愿意频繁的访问您的站点。尽管有效的Web缓存并不是银弹，但设置合适的缓存策略会使您以最小的代价获得可观的收获。
|
||||
|
||||
---
|
||||
|
||||
作者: [Justin Ellingwood](https://www.digitalocean.com/community/users/jellingwood)
|
||||
|
||||
译者：[wwy-hust](https://github.com/wwy-hust)
|
||||
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
推荐：[royaso](https://github.com/royaso)
|
||||
|
||||
via: https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,146 @@
|
||||
Conky - 终极的 X 视窗系统监视器应用
|
||||
================================================================================
|
||||
Conky 是一个用 ‘C’ 语言写就的系统监视器，并在 GNU 通用公共许可协议和 BSD 许可协议下发布，在 Linux 和 BSD 操作系统中都可以获取到它。这个应用是基于 X 视窗系统的，原本 fork 至 [Torsmo][1]。
|
||||
|
||||
#### 特点 ####
|
||||
|
||||
- 简洁的用户界面;
|
||||
- 高配置性;
|
||||
- 它既可使用内置的部件(超过 300 多个) 也可使用外部脚本，来在桌面或其自有容器中展示系统的状态；
|
||||
- 低资源消耗;
|
||||
- 它可显示范围广泛的系统参数，包括但不限于 CPU，内存，swap 分区 ，温度，进程，磁盘使用情况，网络状态，电池电量，邮件收发，系统消息，音乐播放器的控制，天气信息，最新新闻，升级信息等等；
|
||||
- 在许多操作系统中如 CrunchBang Linux 和 Pinguy OS 被默认安装；
|
||||
|
||||
#### 关于 Conky 的少有人知的事实 ####
|
||||
|
||||
- conky 这个名称来自于一个加拿大电视节目；
|
||||
- 它已被移植到 Nokia N900 上；
|
||||
- 它已不再被官方维护；
|
||||
|
||||
### 在 Linux 中 Conky 的安装和使用 ###
|
||||
|
||||
在我们安装 conky 之前，我们需要使用下面的命令来安装诸如 `lm-sensors`, `curl` 和 `hddtemp` 之类的软件包：
|
||||
|
||||
# apt-get install lm-sensors curl hddtemp
|
||||
|
||||
然后是检测传感器：
|
||||
|
||||
# sensors-detect
|
||||
|
||||
**注**: 在被系统提示时，回答 ‘Yes’ 。
|
||||
|
||||
检测所有探测到的传感器：
|
||||
|
||||
# sensors
|
||||
|
||||
#### 样例输出 ####
|
||||
|
||||
acpitz-virtual-0
|
||||
Adapter: Virtual device
|
||||
temp1: +49.5°C (crit = +99.0°C)
|
||||
|
||||
coretemp-isa-0000
|
||||
Adapter: ISA adapter
|
||||
Physical id 0: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
Core 0: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
Core 1: +49.0°C (high = +100.0°C, crit = +100.0°C)
|
||||
|
||||
Conky 既可以从软件仓库中安装，也可从源代码编译得到：
|
||||
|
||||
# yum install conky [在 RedHat 系的系统上]
|
||||
# apt-get install conky-all [在 Debian 系的系统上]
|
||||
|
||||
**注**: 在 Fedora/CentOS 上安装 conky 之前，你必须启用 [EPEL 软件仓库][2]。
|
||||
|
||||
在安装完 conky 之后，只需输入如下命令来开启它：
|
||||
|
||||
$ conky &
|
||||
|
||||
|
||||
正在运行的 Conky 监视器
|
||||
|
||||
这使得 conky 以一个弹窗的形式运行，并使用位于 `/etc/conky/conky.conf` 的 conky 基本配置文件。
|
||||
|
||||
你可能想将 conky 集成到桌面上，并不想让它每次以弹窗的形式出现，下面就是你需要做的：
|
||||
|
||||
将配置文件 `/etc/conky/conky.conf` 复制到你的家目录中，并将它重命名为 `.conkyrc`，开头的点号 (.) 是为了确保这个配置文件是隐藏的。
|
||||
|
||||
$ cp /etc/conky/conky.conf /home/$USER/.conkyrc
|
||||
|
||||
现在重启 conky 来应用新的更改：
|
||||
|
||||
$ killall -SIGUSR1 conky
|
||||
|
||||
|
||||
Conky 监视器窗口
|
||||
|
||||
你可能想编辑位于你家目录的 conky 的配置文件，这个配置文件的内容是非常容易理解的。
|
||||
|
||||
下面是 conky 配置文件的一个样例：
|
||||
|
||||
|
||||
Conky 的配置
|
||||
|
||||
从上面的窗口中，你可以更改颜色，边框，大小，缩放比例，背景，对齐方式及几个其他属性。通过为不同的 conky 窗口设定不同的对齐方式，我们可以同时运行超过一个 conky 脚本。
|
||||
|
||||
**为 conky 使用脚本而不是默认配置以及如何找到这些脚本?**
|
||||
|
||||
你可以编写你自己的 conky 脚本或使用来自于互联网的脚本；我们并不建议你使用你从互联网中找到的具有潜在危险的任何脚本，除非你清楚你正在做什么。然而，有一些著名的主题和网页包含可信赖的 conky 脚本，例如下面所提及的：
|
||||
|
||||
- [http://ubuntuforums.org/showthread.php?t=281865][3]
|
||||
- [http://conky.sourceforge.net/screenshots.html][4]
|
||||
|
||||
在上面的 URL 地址中，你将发现每个截图都有一个超链接，它们将重定向到脚本文件。
|
||||
|
||||
#### 测试 Conky 脚本 ####
|
||||
|
||||
这里我将在我的 Debian Jessie 机子中运行一个由第三方写的 conky 脚本，以此来进行测试：
|
||||
|
||||
$ wget https://github.com/alexbel/conky/archive/master.zip
|
||||
$ unzip master.zip
|
||||
|
||||
切换当前工作目录到刚才解压的目录：
|
||||
|
||||
$ cd conky-master
|
||||
|
||||
将 `secrets.yml.example` 重命名为 `secrets.yml`：
|
||||
|
||||
$ mv secrets.yml.example secrets.yml
|
||||
|
||||
在你能够运行这个(ruby)脚本之前安装 Ruby：
|
||||
|
||||
$ sudo apt-get install ruby
|
||||
$ ruby starter.rb
|
||||
|
||||
|
||||
华丽的 conky 外观
|
||||
|
||||
**注**: 这个脚本可以被修改以展示你当前的天气，温度等；
|
||||
|
||||
假如你想让 conky 开机自启，请在开机启动应用设置(startup Applications) 中添加如下的几行命令：
|
||||
|
||||
conky --pause 10
|
||||
save and exit.
|
||||
|
||||
最后。。。 如此轻量级且吸引眼球的实用 GUI 软件包不再处于激活状态且官方不再进行维护了。最新的稳定发布版本为 conky 1.9.0， 于 2012 年 5 月 3 号发布。在 Ubuntu 论坛上，一个有关用户分享 conky 配置的主题已经超过了 2000 多页。(这个论坛主题的链接为: [http://ubuntuforums.org/showthread.php?t=281865/][5])
|
||||
|
||||
- [Conky 主页][6]
|
||||
|
||||
这就是全部内容了。保持联系，保持评论。请在下面的评论框里分享你的想法和配置。
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/install-conky-in-ubuntu-debian-fedora/
|
||||
|
||||
作者：[Avishek Kumar][a]
|
||||
译者：[FSSlc](https://github.com/FSSlc)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/avishek/
|
||||
[1]:http://torsmo.sourceforge.net/
|
||||
[2]:http://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/
|
||||
[3]:http://ubuntuforums.org/showthread.php?t=281865
|
||||
[4]:http://conky.sourceforge.net/screenshots.html
|
||||
[5]:http://ubuntuforums.org/showthread.php?t=281865/
|
||||
[6]:http://conky.sourceforge.net/
|
||||
Loading…
Reference in New Issue
Block a user