So, we finally released the thing I've been working on for the last six months at Canonical - a live kernel patch service, that allows users to put off rebooting until it's convenient, without being at risk from recently-found vulnerabilities. It's targeted at servers, but desktop users can benefit from it as well.
I've been heavily invested in the project, and it's really great to have it out finally.
Here's some links to stories about it:
A link at Reddit (how dare you insert crap into my post!)
If I worked the way I am being expected to vote, I wouldn't have a job, since #1 and #2 both are horrible choices.
Actually, it's pretty similar: #1 is horrifically corporate, very susceptible to viruses, sloppy, easily hacked, and most people hate how it works, but think supporting it should be mandatory.
#2 is all flash and no substance, self-aggrandizement and ego, paired with one-sided draconian policies resting on top of exploitation of other people's work. Moreover, take the fancy plastic off and inside is exactly the same shit as #1.
Don't expect me to fix your computer, or your government, if you can't admit that you willingly picked something broken.
I've been third party for DECADES and it's worked just fine for me so far. I don't need to support you.
Need to run the Windows plugins for Flash or Silverlight on Ubuntu?
Try Pipelight. I used this to watch the 2016 Olympics and it worked really well, just don't have more than one going at once. ;)
Since I figured part of this out, I felt like I'd share it.
To use the 'content' interface to share files, you need to have special YAML in both the consuming snap and the producing snap. These dictate which paths are shared, and where they show up in the consuming snap's file space.
In the producing snap's yaml, add:
read: [ path1, path2 ]
This goes in the TOP LEVEL of the yaml. Then, in the consuming snap, you have to add a similar block to the top level there:
Note that the consuming snap MUST have a directory to serve as a mount point for the producer's files, and you have to create this yourself. I have just been using a directory containing a directory, and this yaml at the bottom of the parts list:
Then, just have mountpoints/producer-mount in there, and it should all just work.
I'll be updating this post all weekend.
Jade Jones - 12-4, 7-2, 9-4, 16-7 GOLD medal!!! :D
Lee Dae Hun - 6-W, lost in QF 8-11, Repechage 14-6
Lutalo Muhammed - 14-0, 9-2, 12-7, 6-8 Silver! (Ouch though!)
Paige McPherson - 5-6 :(
Mahama Cho 12-6, 3-3 GP, 1-4 loss, 4-5 :(
Jackie Galloway 5-0, 0-0 Decision, 0-0 Decision loss, 2-1 BRONZE medal!
Bianca Walkden 14-1, 5-0, 1-1 GP loss, 7-1 BRONZE medal!
If you are using an SD-based hard drive with your Atari ST, it is very easy to move files back and forth from Ubuntu using the mformat/mcopy/mdelete/etc series of commands. The magic option is -i; this allows you to specify an image to be used as a FAT disk, and is smart enough to understand the Atari ST disk format.
In my case, when I attached my SD card to my workstation, it appears as /dev/sdc, with four 256mb partitions. Mounting these is difficult if you are using a TOS 1.0 compatible disk format, which is the only thing my first-run Atari 1040 STF understands. It was easy to copy files, though:
$ sudo mcopy -s -i /dev/sdc1 * ::
The command must be used under sudo to write to the device. the :: represents the root of the FAT filesystem; if you want to copy files to a subdirectory, or copy from the Atari back to Ubuntu, just format your paths like this:
::/folder/file <-- is DISK:/FOLDER/FILE
Ubuntu makes it incredibly easy to sling ST files around, too. Want to extract the files from an image? Just do:
$ mcopy -s -i IMAGE.ST :: .
It will pull the files right out.