The plugin is actually just one line of code (more or less), so it’s super easy to install and use (and to uninstall). There aren’t any options or configuration screens. I’ve been running it for the past couple of years without any problems, so you shouldn’t have any, either. But if you do, just let me know!
If you’re still wondering, why would I want this? Well, do you like it when you visit a website that sets cookies in your browser, but never clears them when you log out? If that’s not enough of an explanation, please see the plugin page.
The plugin is hosted on wordpress.org, so please go there to download the plugin or submit any support requests.
]]>dnf clean packages
will erase everything in the package cache.
But what if you want to preserve the latest version of each package and just delete the outdated versions? For example, to keep a local cache of the latest version of each package you’ve installed, and so that DRPM will still work on your next dnf upgrade.
Here’s how:
find /var/cache/dnf -maxdepth 2 -type d -name 'packages' -print0 | xargs -0 -n 1 -P 4 sh -c 'cd $1; for x in `ls *.rpm | grep -Po "^.*?(?=-[0-9])" | sort -ru`; do ls $x-*.rpm | egrep "^$x-[0-9]" | head -n -1 | xargs rm -f; done' sh
Disk space used before and after on my laptop:
du -hs /var/cache/dnf
7.5G /var/cache/dnf
# run one-liner above
du -hs /var/cache/dnf
1.8G /var/cache/dnf
]]>EFF’s Let’s Encrypt initiative just made getting a free, CA-signed server certificate easier than it’s ever been before. Running a single command generates everything you need, obtains the public cert and even installs it into your webserver of choice. So let’s encrypt, and move the web closer to HTTPS everywhere!
Here’s a quick tutorial for using Let’s Encrypt with Dreamhost’s shared hosting. It’s not quite automatic, since you’ll have to copy-paste 3 things into boxes via the Dreamhost web panel, but it’s a lot simpler than the alternatives. As someone who’s done this the old way countless times, Let’s Encrypt was shockingly easy!
First, let me start by saying I ran all this locally on my laptop running Fedora — if you’re stuck on Windows or OS X without a friendly package manager, I can’t help you install Let’s Encrypt, but there are instructions on the site. It’s CLI-only, so you can also easily run Let’s Encrypt in an SSH session on a remote Linux machine or local virtual machine.
On Linux, here’s all I did to install Let’s Encrypt, run it, and paste the generated server certificate chain and private key into the Dreamhost web panel.
First, download Let’s Encrypt and run letsencrypt-auto --help
once to install any missing dependencies.
git clone https://github.com/letsencrypt/letsencrypt.git
cd letsencrypt
./letsencrypt-auto --help
Next, you’ll run letsencrypt-auto
in manual mode to create (but not install) the generated certificates. In this example I’ll just create one certificate, for “example.com”, but you can add more than one -d
parameter to generate as many certificates at once as you like.
./letsencrypt-auto certonly --manual -d example.com
The first time you run the Let’s Encrypt interactive client, it will ask you for an email address and to agree to the Terms of Service — you’ll want to give a good email address, since it’ll be used for emergency key recovery, but the email address you use doesn’t have to have anything to do with the domain name you’re certifying.
Next, the client will display a message that starts like this:
Make sure your web server displays the following content at
http://example.com/.well-known/acme-challenge/RcapSBi_ZOlYnrByap1cRRrHln1lzKOIXwg2NowrZt5 before continuing:
RcapSBi_ZOlYnrByap1cRRrHln1lzKOIXwg2NowrZt5.lvgVdH1KypqK217AlBi9qE6ZYiusmdqZrzYNqOMGp3o
...
Press ENTER to continue
So, before you press Enter, you need to create that file at that URL on your site, so that Let’s Encrypt can validate that you actually control the domain. You can do this by creating the file locally and uploading it via SFTP or SCP, or you can SSH to your hosting account and just create it there. For example, I did:
ssh example.com
cd example.com/htdocs
mkdir -p .well-known/acme-challenge
echo "RcapSBi_ZOlYnrByap1cRRrHln1lzKOIXwg2NowrZt5.lvgVdH1KypqK217AlBi9qE6ZYiusmdqZrzYNqOMGp3o" > .well-known/acme-challenge/RcapSBi_ZOlYnrByap1cRRrHln1lzKOIXwg2NowrZt5
Before continuing, check that the challenge URL now loads correctly through your browser, and press Enter. Let’s Encrypt will exit, it’s already done!
IMPORTANT NOTES:
- If you lose your account credentials, you can recover through
e-mails sent to youremail@example.com.
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
expire on 2016-03-03. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
- Your account credentials have been saved in your Let's Encrypt
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Let's
Encrypt so making regular backups of this folder is ideal.
- If like Let's Encrypt, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
So now, you just need to log into the Dreamhost panel to install the certificate. Under “Domains” go to “Secure Hosting” and click the “Add Secure Hosting” button. Select the domain name (“example.com”) you’d like to host securely. (You don’t need to add a unique IP.)
Dreamhost will give you a success message saying that it’s started secure hosting using a self-signed certificate. So, the final step is to replace that cert with the one you generated using Let’s Encrypt.
Click the Edit button next to your domain and then choose “Manual configuration.” You’ll now see 4 boxes that you need to update:
/etc/letsencrypt/live/example.com/cert.pem
— paste the contents of that file into this box.openssl
command openssl rsa -in /etc/letsencrypt/live/example.com/privkey.pem
to dump the RSA PRIVATE KEY to screen, and paste the results into this box./etc/letsencrypt/live/example.com/chain.pem
— paste the contents of that file into this box.When you’re done, it should look something like this:
Click “Save changes now!” and you’re done!
You may already know that Dreamhost has its own API that you can use to control certain functions of your hosting account, so wouldn’t it be great if there were a Dreamhost module for Let’s Encrypt that completely automated this whole process?
Then you could just run Let’s Encrypt in a cronjob once every three months, and be done with this certificate nonsense forever!
Unfortunately, at present the API doesn’t include methods for modifying the SSL certificate configuration, so it’s just a pipedream for now. But if that’s something you’d like, tell Dreamhost, and maybe they’ll make it happen.
]]>First, download and build Brotli if it’s not already installed on your system. You’ll need to run make
in the “dec”, “enc” and “tools” directories to build the brotli
executable. A quick note here, if you’re using an older version of GCC you might get an error message because your g++ doesn’t support the -std=c++11
flag. I ran into this on an older Debian server (GCC 4.6.3 from 2011), changed -std=c++11
to -std=c++0x
in the CXXFLAGS
line of shared.mk
, and the build completed normally.
Next, compress your files. If you already have static files compressed with the .gz
extension, here’s a one-liner to recompress them all using brotli
:
for x in `find . -type f -name '*.gz'`; do gzip -dc $x | brotli -fZ -o ${x%.gz}.br; done
Last, it’s time to add support for br-encoded files to Apache. You can do this server-wide, or in .htaccess
. Here’s a quick .htaccess
example that includes support for both Brotli and gzip pre-compressed files:
FileETag None
<Files *.js.gz>
AddType "text/javascript" .gz
AddEncoding gzip .gz
</Files>
<Files *.css.gz>
AddType "text/css" .gz
AddEncoding gzip .gz
</Files>
<Files *.js.br>
AddType "text/javascript" .br
AddEncoding br .br
</Files>
<Files *.css.br>
AddType "text/css" .br
AddEncoding br .br
</Files>
RewriteEngine On
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [L]
Finally, let’s test! An easy way to do this is using curl
. For example:
curl https://example.com/css/example.css -H 'Accept-Encoding: br' > file.out
Curl will download and save the br-encoded file example.css
to file.out
, which will be identical to example.css.br
on your server.
Anyway thanks to this thread and this post, there’s any easy fix. Just add this to ~/.config/gtk-3.0/gtk.css
/* No line below the title bar */
.ssd .titlebar {
border-width: 0;
box-shadow: none;
}
]]>Of course, Deflate and its most widespread implementation, zlib, aren’t dead yet, not by a long shot. But what these new LZ77 algorithms offer is significant enough performance gains to justify widespread implementation, and adoption by the W3C. And they have the backing of companies such as Google and Apple, which means they’ll ship on tens of millions of devices and browser installs.
For online encoding and decoding — i.e. transport encoding — where encode/decode speed are critical, Zstandard and LZFSE offer substantial performance/energy usage improvements over Deflate, while roughly matching its compression ratio, by employing finite state entropy (FSE) coding in place of older Huffman and arithmetic methods.
For offline encoding and online encoding — i.e. static Web assets, or APKs on Android — Brotli offers 20% or greater improvement in compression ratio versus Deflate while providing slightly improved decode speed.
(For pure offline compression use cases, such as file archives, LZMA and ZPAQ provide still higher compression ratios at the cost of much longer compression and decompresssion times.)
A subset of Matt Mahoney’s large text compression benchmark (be sure to refer to his current benchmark results, I won’t be updating this table) illustrates these key characteristics and tradeoffs:
Program | Ratio | Compression | Decompression | Memory (Compression) |
---|---|---|---|---|
zpaq 6.42 | 14.6% | 6699 | 14739 | 14000 |
xz 5.2.1 | 20.2% | 5876 | 20 | 6000 |
brotli 21 Sep 2 | 24.4% | 4386 | 5 | 294 |
bzip2 1.0.2 | 25.7% | 379 | 129 | 8 |
zopfli | 31.3% | 2237 | 13 | 25 |
gzip 1.3.5 | 32.6% | 101 | 17 | 1.6 |
zstandard | 35.9% | 7.7 | 3.8 | 1.6 |
A quick run-down of each algorithm’s design and anticipated applications:
for
loop and should work on any POSIX-compliant system. Take note that it will delete your original files! The idea is to make a copy of your music folder first, and then run this command on the copy.
find -name "*.flac" -exec sh -c 'ffmpeg -i "$1" -acodec libmp3lame -aq 4 "${1%.flac}.mp3" && rm -f "$1"' _ {} \;
And that’s it!
If you have a COW filesystem like btrfs, you can use the reflink copy option to make a duplicate of your entire Music folder (to run this command on) almost instantaneously, i.e. cp -pr --reflink Music Music-mp3
rm
command, which will delete all your flac originals. This is on purpose because we want to start with a directory tree of *.flac and convert everything to *.mp3. If you don’t want this, then remove the rm
command.For Apple Lossless, it’s:
find -name "*.flac" -exec sh -c 'ffmpeg -i "$1" -acodec alac "${1%.flac}.m4a" && rm -f "$1"' _ {} \;
Already available to anyone willing to do a little work with off-the-shelf hardware like Raspbery Pi, Outernet now have an integrated, solar-powered receiver called Lantern that doubles as a charger, theoretically enabling offline, anonymous read-only access to Web content anywhere in the world.
Lantern downloads editor-selected content (slowly, remember this is satellite) and saves it locally, then serves it up locally over HTTP via wifi. Think of it as Voice of America or BBC World Service for the digital age, except administered by MDIF, who have a strong track record investing in innovative media organizations that promote press freedom and independent media in “challenging” environments — places where independent media face censorship and worse.
And it gives you something to read anytime you’re far away from the nearest cellular signal — with complete anonymity, since this is a one-way broadcast, something that’s obviously critical in places where the terrestrial Internet is tracked or censored by governments or ISPs (i.e. everywhere, to varying degrees).
Code has been open-sourced, some interesting content distribution partnerships have been agreed, and Outernet have also begun an initiative to crowd-source editorial function to ensure interesting, comprehensive selection of content is broadcast using limited satellite carrying capacity. I don’t have one so I can’t say much more, it obviously will require healthy ongoing funding and engagement to be viable, which means bootstrapping a user base and community of contributors.
Looks cool, and compared to prototype IoT devices like Chumby and Nabaztag on my shelf, it’s privacy-enabling, not privacy-surrendering. Internet-based media are wonderful, but also a serious regression from a consumer-privacy perspective compared to “old tech” like newspapers and broadcast radio. One-way information flow should have a future, not just a past.
]]>Before you install, you might want to read more about the kernel’s features and design goals in my post about the S kernel. The Optimus V is not identical to the S (there are a couple of minor hardware differences between the phones, such as swapped Home and Menu buttons), but unlike some other kernels released for the V (such as ports of Xionia), mine is not a ported S kernel, it is a native V kernel. So, it is a drop-in replacement for the stock LG kernel.
If that didn’t make sense (“I thought you said to read about your kernel for the S, what gives?”), I’ll put it another way. Think of my kernel only as a changeset to the original (add overclock, add interactive cpu scaling, add TUN/TAP network and EXT filesystem drivers as modules; subtract debugging, ethernet and other unnecessary bloat; build the whole thing with a better toolchain). The S kernel is that changeset applied to the official LS670 sources from LG. The V kernel is that changeset applied to the official VM670 sources.
The end result is a kernel that is perfect for your Optimus V running either the stock OS or any LG-based ROM — that means, at present, Android 2.2.x or Froyo-based ROMs. But not perfect for Cyanogen or other Gingerbread/Android 2.3-based OSes. Just like you shouldn’t run a Gingerbread/2.6.35.7 kernel on a Froyo-based OS, you shouldn’t run this Froyo/2.6.32.9 kernel on a Cyanogen-based OS. Got it?
Of course, that’s just for now. As soon as LG does its official release of Gingerbread/2.3 for these phones, I’ll update this kernel from the new official sources.
This kernel has survived its initial shakedown on the Android Central forums, but if you choose to install it, the standard disclaimers apply: No warranties expressed or implied, it’s your responsibility to understand exactly what you’re doing, so if you kill your phone I assume no responsibility.
Requirements: To start with, you’ll need to have rooted your phone. You’ll also need a custom recovery. I’ve used koush’s AnyKernel template to package the .zip, so you should be able to flash this kernel over top of the stock LG OS or any custom ROM.
So, if you understood all of that, the rest should be easy. Download picasticks kernel picasticks-07a.zip, copy it to /sdcard/, reboot your phone to your custom recovery, and flash the .zip. Reboot and enjoy!
Home and Menu keys: These hardware keys are mapped by the kernel, but the mappings can also be reassigned in the file thunder_keypad.kl
. If you have previously installed a custom ROM/kernel on your V, chances are that it contained an incompletely ported S kernel with the keys swapped, and this bug “fixed” by reswapping the key assignments in the thunder_keypad.kl
keymap. My kernel, built for the V, doesn’t require this hack. So, my .zip installer includes a script that checks for a swapped mapping, and if found, replaces your keymap file with an original, unmodified copy. It should only do this if it finds the Menu key (139) incorrectly mapped to Home, but ignore other custom key assignments. In any case, if you’re concerned about your customized thunder_keypad.kl
being overwritten, just back it up before flashing the kernel.
As we have learned from LG, source code release is an important part of distributing software covered by the GPL!
I’m not going to publish a giant tarball (yet) since it’s 100% LG source + my changeset, which I’ve made into a single patch. Therefore, to duplicate my build source:
cd lg_kernel && patch -p1 < kernel.diff
And here are my changes to the LG kernel configuration .config
.
Both patches, by the way, are the same as the ones I'm using for the S, so these links are to the same files (that's what I meant earlier about applying the same changeset to both kernels!).
For more information and full credits, see my original post.
thunder_keypad.kl
and script to check the phone's current keymap for swapped Home/Menu keys and, if found, replace with the original.So, all is well in this small corner of the open-source world. I’ve downloaded the new source code (labeled “LGVM670(Thunder) Android Froyo/kernel bugs were fixed” on LG’s download site), and verified that the fixes were made and that the new code builds cleanly.
In case you’re interested in the differences between the Optimus S and Optimus V (LS670 and VM670, respectively), here’s a diff of the kernel sources that I’ve made.
]]>