Set a cookie on the client machine to identify the user.
Pros: Definitely unique per session
Cons: Easy to remove or prevent (even for people with limited technical knowledge), only apply to one browser, easy for a script to bypass
IP address
Use the user’s IP address to identify the user.
Pros: Changes infrequently, works across browsers, requires technical knowledge to spoof or use a proxy server
Cons: Not necessarily unique: one IP address can easily apply to entire homes/buildings/offices behind a network, and for some ISPs end user IP addresses might be reassigned
Browser fingerprinting
Use all browser data passed to the server (not just user agent, but also OS, screen resolution, and a number of other things) to generate a unique browser fingerprint.
Pros: High probability of being unique, opaque to the end user (changing IP addresses or clearing cookies won’t bypass it)
Cons: Probably too unique — any change in browser condition (or browser) will change the fingerprint (though you can choose only a subset of supplied browser information to balance fingerprint volatility and uniqueness), can be bypassed by scripts
You can, of course, also use multiple methods. Which method you use really depends on your specific use case. For many cases, just a simple cookie will do. If you want some defense against scripts or other methods of bypassing, add an IP address rate limit. You can also attempt to gather as much information as possible and use some sort of heuristic algorithm to try to find people that are bypassing the system for uniqueness that you have in place.
Automatically playing audio and video on the web is a powerful capability, and one that’s subject to different restrictions on different platforms. Today, most desktop browsers will always allow web pages to begin <video> or <audio> playback via JavaScript without user interaction. Most mobile browsers, however, require an explicit user gesture before JavaScript-initiated playback can occur. This helps ensure that mobile users, many of whom pay for bandwidth or who might be in a public environment, don’t accidentally start downloading and playing media without explicitly interacting with the page.
It’s historically been difficult to determine whether user interaction is required to start playback, and to detect the failures that happen when (automatic) playback is attempted and fails. Various workarounds exist, but are less than ideal. An improvement to the underlying play() method to address this uncertainty is long overdue, and this has now made it to the web platform, with an initial implementation in Chrome 50.
A play() call on an a <video> or <audio> element now returns a Promise. If playback succeeds, the Promise is fulfilled, and if playback fails, the Promise is rejected along with an error message explaining the failure. This lets you write intuitive code like the following:
var playPromise = document.querySelector('video').play();
// In browsers that don’t yet support this functionality,
// playPromise won’t be defined.
if (playPromise !== undefined) {
playPromise.then(function() {
// Automatic playback started!
}).catch(function(error) {
// Automatic playback failed.
// Show a UI element to let the user manually start playback.
});
}
In addition to detecting whether the play() method was successful, the new Promise-based interface allows you to determine when the play() method succeeded. There are contexts in which a web browser may decide to delay the start of playback—for instance, desktop Chrome will not begin playback of a <video> until the tab is visible. The Promise won’t fulfill until playback has actually started, meaning the code inside the then() will not execute until the media is playing. Previous methods of determining if play() is successful, such as waiting a set amount of time for a playing event and assuming failure if it doesn’t fire, are susceptible to false negatives in delayed-playback scenarios.
PHP QR Code is open source (LGPL) library for generating QR Code, 2-dimensional barcode. Based on libqrencode C library, provides API for creating QR Code barcode images (PNG, JPEG thanks to GD2). Implemented purely in PHP, with no external dependencies (except GD2 if needed).
Some of library features includes:
Supports QR Code versions (size) 1-40
Numeric, Alphanumeric, 8-bit and Kanji encoding. (Kanji encoding was not fully tested, if you are japan-encoding enabled you can contribute by verifing it 🙂 )
Implemented purely in PHP, no external dependencies except GD2
Exports to PNG, JPEG images, also exports as bit-table
TCPDF 2-D barcode API integration
Easy to configure
Data cache for calculation speed-up
Provided merge tool helps deploy library as a one big dependency-less file, simple to “include and do not wory”
Linux is borrowing unused memory for disk caching. This makes it look like you are low on memory, but you are not! Everything is fine!
Why is it doing this?
Disk caching makes the system much faster and more responsive! There are no downsides, except for confusing newbies. It does not take memory away from applications in any way, ever!
What if I want to run more applications?
If your applications want more memory, they just take back a chunk that the disk cache borrowed. Disk cache can always be given back to applications immediately! You are not low on ram!
Do I need more swap?
No, disk caching only borrows the ram that applications don’t currently want. It will not use swap. If applications want more memory, they just take it back from the disk cache. They will not start swapping.
How do I stop Linux from doing this?
You can’t disable disk caching. The only reason anyone ever wants to disable disk caching is because they think it takes memory away from their applications, which it doesn’t! Disk cache makes applications load faster and run smoother, but it NEVER EVER takes memory away from them! Therefore, there’s absolutely no reason to disable it!
If, however, you find yourself needing to clear some RAM quickly to workaround another issue, like a VM misbehaving, you can force linux to nondestructively drop caches using echo 3 | sudo tee /proc/sys/vm/drop_caches.
Why does top and free say all my ram is used if it isn’t?
This is just a difference in terminology. Both you and Linux agree that memory taken by applications is “used”, while memory that isn’t used for anything is “free”.
But how do you count memory that is currently used for something, but can still be made available to applications?
You might count that memory as “free” and/or “available”. Linux instead counts it as “used”, but also “available”:
Memory that is
You’d call it
Linux calls it
used by applications
Used
Used
used, but can be made available
Free (or Available)
Used (and Available)
not used for anything
Free
Free
This “something” is (roughly) what top and free calls “buffers” and “cached”. Since your and Linux’s terminology differs, you might think you are low on ram when you’re not.
How do I see how much free ram I really have?
To see how much ram your applications could use without swapping, run free -m and look at the “available” column:
$ free -m
total used free shared buff/cache available
Mem: 1504 1491 13 0 855 792
Swap: 2047 6 2041
(On installations from before 2016, look at “free” column in the “-/+ buffers/cache” row instead.)
This is your answer in MiB. If you just naively look at “used” and “free”, you’ll think your ram is 99% full when it’s really just 47%!
A healthy Linux system with more than enough memory will, after running for a while, show the following expected and harmless behavior:
free memory is close to 0
used memory is close to total
available memory (or “free + buffers/cache”) has enough room (let’s say, 20%+ of total)
swap used does not change
Warning signs of a genuine low memory situation that you may want to look into:
available memory (or “free + buffers/cache”) is close to zero
swap used increases or fluctuates
dmesg | grep oom-killer shows the OutOfMemory-killer at work
How can I verify these things?
See this page for more details and how you can experiment with disk cache to show the effects described here. Few things make you appreciate disk caching more than measuring an order-of-magnitude speedup on your own hardware!