Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.
I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.
Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.
Maybe it's the company I keep (on Twitter and the Fedora Planet anyway), but I keep hearing about Docker and its use of Linux Containers to deliver stand-alone applications:
Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.
Docker containers can encapsulate any payload, and will run consistently on and between virtually any server. The same container that a developer builds and tests on a laptop will run at scale, in production*, on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.
...
* Please note Docker is currently under heavy developement. It should not be used production (yet).
Synchronizing a filesystem between a local drive and a server via ftp (or, as suggested, rsync or Unison)
Is it possible to synchronize a local filesystem (really a directory and everything below it) with a filesystem/bunch-of-directories-and-files on a server with an ftp client application like FileZilla?
What I'm looking to do is create files and directories on my local drive and then use the client application to automatically (or at least semi-automatically) upload those new items to the server without me having to "drag them over" in the FTP client. I want to keep both directories in sync, much like Dropbox does, but without a third-party service in the middle, and without needing to upload the whole directory and contents, but just the changed/new items.
On the FileZilla forum, it is suggested that the tool for this job is not ftp but rsync.
I use rsync all the time for my local backups, and I'm not terribly well-versed in using it with ssh over the network, but I will look into this and see what I can come up with.
Others are suggesting Unison (1), (2), (3), (4) (5), which builds on rsync.
To make a long story I don't yet understand a whole lot shorter, rsync works in one direction, Unison in both, which can be better for backups when things are potentially changing on both server and client (or server and server, for that matter).
Problem with Unison: You must have Unison on both systems, and my shared hosting account's CentOS box doesn't offer it. It does have rsync, so I might have to go with that. Or I could just continue with my current arrangement of either working with the server's filesystem mounted over sftp most of the time, pushing local files over sftp some of the time, and using sftp to pull down backups on a regular basis.
Possible solution -- Csync: Rob suggests in the comments below that csync could work for this task. It only needs to be on the client side, and it both pushes and pulls files.
I've already installed it, and I'll look into making it work.
What I'm trying to do is keep filesystems in sync across different systems where there are potentially new and changed files on both sides.
The Ghost team has pushed out a release to the project's some-6,000 Kickstarter backers. Ars Technica staffer Lee Hutchinson reviews and posts in Ghost.
The double-paned Markdown/HTML view looks a lot like Ode's EditEdit, right?
According to the Ghost blog, while the code is only going to Kickstarter supporters right now, there will be a public release in the weeks ahead.
Does the release announcement include the names of every one of those 6,000 people? I think it does.
Warning: The AMD Catalyst 13.9 Linux video driver was on the site this morning but has disappeared since then. As of 4 p.m. Pacific time on Sept. 19, 2013, it has not yet reappeared. AMD, it's your move.
Before the driver disappeared, here is what I wrote:
Now that the 3.11 version of the Linux kernel is available on my Fedora 19 system, AMD has released a new version of its closed-source, stable driver, version 13.9, that brings support to ... the 3.10 kernel.
Not that I haven't been running the 13.6 (suspend/resume worked) and 13.8 betas (suspend/resume didn't work in 13.8 beta 1, not sure about beta 2), because I have.
You can download the new driver here, though I recommend NEVER installing from what AMD provides and always, ALWAYS using a version packaged for your distribution, which for Fedora means the packages provided by RPM Fusion.
Running Fedora and needing AMD Catalyst for working 3D graphics means willfully ignoring new kernels that aren't yet supported and accompanied by a new kmod-catalyst
package. That's what I'm doing with the new 3.11.1 kernel that moved into Fedora 19 today. I won't install a 3.11 kernel until there's a corresponding kmod-catalyst
package from RPM Fusion to go with it. And given that this new 13.9 release of AMD Catalyst only supports the 3.10 kernel and isn't yet in the RPM Fusion repository (which, given the fact that it was just released, I totally understand), I'll wait for the next kmod-catalyst
to roll onto my machine and once again test suspend-resume. If it works (like it did during the brief 13.6 beta window), I'll be of a mind to stick with the 3.10 kernel for a good long while.
But if suspend-resume doesn't work with the combination of Linux kernel 3.10.x and Catalyst 13.9, it'll be back on the beta train until AMD decides to better-support the GPUs it makes, including my AMD Radeon HD 7420g.
Potential problem: I just checked the AMD page, and the new driver is (hopefully temporarily) gone.
There's still more to do, but I have enough hacks roughed in to flip the switch on the responsive version of my Ode site.
Thanks to Hans Fast who did most of the work on this here and here.
I'll detail what changes I made to my main Ode theme's HTML and CSS in a near-future post (which I'm already working on).
Responsive design is a big thing for me. It was easy to do in Ode -- and easier thanks to hints from Hans. I still have quite a few elements in Ode's main Logic theme to work on, and I'll knock them down as I get the time to do it.
Thanks once again to Hans Fast for his code, and to Rob Reed for shipping such good code to start with in Ode.
Recent changes:
I tried to code the CSS so the "desktop" layout is what you see in tablets as well. I continue to think that most web sites, including this one, look pretty good on the standard 10-inch tablet (like a full-size iPad), and having sidebars pushed to the bottom is unnecessary on those devices.
So I simplified part of the CSS to make the site stay "normal" until 400px in screen width instead of 800px.
I also made some changes in sidebar behavior. When the screen is small, the sidebar not only goes to the bottom of the page, its text goes from float: right
to float: left
, and the colored image overlay on the sidebar disappears.
I've been meaning to roll the rest of the posts in my FlatPress blog centered on Debian into this Ode site.
In the past, I've moved quite a few of them in here, but there were about 30 or so from the early days of the FlatPress blog that I had yet to move.
I plowed through about 20 today and have 17 more to go. Rather than taking HTML source from FlatPress, I'm copy/pasting regular text from the FlatPress blog into text files and using Markdown to re-create the links and bolding.
Through the Ode forum, I just found Jim's graphic design and history site, Codex 99 Annex.
It's nice to see what you can do with Ode when it comes to design. (hint: just about anything).
This guy lost it all when he didn't backup a decade of web content: http://www.craiglockwood.co.uk/
Level of difficulty: Medium to high
A utility that will crawl the Ode documents folder and create a list of links by year and month that can be used in the sidebar of the blog as an archive. Another possible archive listing (which I had in Movable Type and quite liked) is a single page with a list of every individual entry by title.
While this could be done with its own Ode addin, this functionality could be folded into the Indexette addin. In this case, the "reindex" call would also build the year/month and full-archive index HTML, which could then be inserted in the appropriate places in the theme file (for the year/month index) and a single "archive" page for the full archive.
Am I missing something, or is this an easy project? It's possible to reuse code from Blosxom, PyBlosxom, or just about any blogging system that offers this functionality.