jermy

You can get a similar effect, but in a different manner, with attempting to plug a CD or MP3 player into certain mixing desks. The obvious approach, when you have a 3.5mm (1/8") stereo jack from the device, to attach it into one of the 1/4" line input sockets with a suitable stereo adaptor.

In most cases with older desks, this will be fine (you'll only get the left channel from the source). Some newer/smaller desks have a balanced jack input instead or as well as a balanced XLR, and plugging in an audio source will get exactly the same effect as described in the thread, since the left and right channels will be treated as a balanced pair and subtracted.

Cheapest approach to connect such a device to a mixer is a 3.5mm to 2x phono plugs and a pair of phono to 1/4" jack adaptors, connect to two channels on the mixer, and fully pan left and right.

(Never really thought about it before, but here in the UK it seems perfectly normal to refer to 1/4" and 3.5mm plugs at the same time)

Supermicro's equivalent IPMI remote access (iKVM) is also Java

Indeed - in this particular series (The Night's Dawn Trilogy) space warfare was conducted at very long range by kinetic drones, fired from spherical ships.

Ah, apologies, I'll eat my hat (or buy you a beer sometime - you folks Covent Garden based?).

I had assumed Kompressor also handled REDCODE with its hardware requirements, as well the Avid Connection Manager and other Quicktime codecs.

The REDCODE format is proprietary - any of the above need to have the Red quicktime or AMA plugin to access the content.

For amusement, see 'Baselight Kompressor' for what a linux-based grading system has to do to handle red content.

As only a minor nitpick (my excuse is that this is my day job), you've got it the wrong way round - REDCODE is actually storing data as RGB, whereas 'every other camera' is almost certainly using a MPEG-based codec and storing it as YUV with chroma subsampling - somewhere between 4:1:1/4:2:0 to 4:2:2 depending on the camera in use.

As with any lossless compression, it's a compromise between having almost all of the data shot to work with versus pretty much having to always do a full grade on any content you get and the additional online storage space needed in post-production.

It depends on your use case - either you accept there is a write hole that the update wont appear until that host comes back online and other hosts can relay the change, or you add application-level checking to not return to the user in the first instance until the change hits at least another host.

In your scenario, yes. The two changes would be a conflict, but hopefully (if the user makes the same change) your conflict-resolution code would realise it is the same and merge them correctly. I fear I don't know how MySQL::Replication handles this, but it has to be application-level logic, so I assume it will allow you to override a default of, say, last-modification-wins.

I like Slide 251: 'solve it at the application layer' :)

I'm part of a team responsible for cloud-based video editing software. We use multi-master replication (perhaps also known as optimistic replication) with our own tools throughout, but it does require careful design - keep as much data as immutable as possible, every piece of data that might be updated by different machines at the same time should have its own row, GUIDs on each row.

Each machine can generate its own local IDs, which look a lot like a timestamp with some unique stuff on the end. Each row gets a GUID and a 'version' ID column, and we only update relayed database updates if the incoming version is newer. This is largely last-timestamp-wins for the case of conflicts (rare because of design decisions), but there is some Lamport timestamp behaviour in there too for updating a existing row.

The main downside is still that all machines need to handle every write, but with batching up incoming processing into larger transactions, we've had no problems with quite a number of database updates on a dozen commodity machines. Obviously filtering into different shards would be an easy solution.

I'm looking forward to seeing what other people are doing with multi-master replication.

Because the newer login system requires you to move away from having any easy to remember username (eg. someperson) that only needs to be unique on a particular Basecamp instance, to picking a harder to remember new username (eg. someperson5946) that needs to be unique everywhere.

What is described is already reality - I see it every day.

I work for a company writing its own video codecs, who have a format that downloads a 70KB jar file before streaming the video. It's a Java applet (and still supports Java 1.1 - we've been doing this for a number of years now) and largely allows the model that Stanislav wishes. Is it ideal? Probably not. We can't do fullscreen or hardware-optimised playback. We have to implement our own controls that are out of place of the L&F of the OS and browser. We need people to install the Java VM. On Java versions older than JDK6u18 we still only get to use 64MB of memory (on a 2GB machine? Hah!). Not always going to work on your latest smartphone.

On the flip side, I also see a lot of video container formats where people try to standardise something as generic as possible. Particularly OMFI (Bento), Quicktime, AAF. The simplest AAF File which simple refers to a piece of video content elsewhere is 250KB, because it has to define a complete vocabulary of items that it might deal with in the file, and jumps from pointer to pointer to actually get to the data. It's pretty much the closest we have to Stanislav's 1961 Air Force quote example, with everything short of actually including a decoder specification for the audio and video content. It's a minefield to work with. It's too flexible for its own good, and reading or writing it is anything but a trivial task (cue large libraries, larger than video decoders, to do that. Anything but ideal).

So, one side involves a virtual machine to standardise hardware, and the other needs large libraries to parse and emit even the simplest of files. I've seen this world, and I think I'd rather have well-implemented standard decoders working on simpler wrappers instead.

True, although I often fall into a worse trap when that 'Get back to work!' message comes up by seeing what's on Reddit instead.

Odd that SSDs aren't mentioned in the article at all - they would mostly avoid many of the criticisms levelled at disks without requiring redevelopment

Yes, producing encoded content would indeed require you to have a licence. But, if you're running such a service, at least licences are cheap (even if the pricing model is still set around the concept of hardware devices).

A recent paper uses it to model the UK Motorway network - http://arxiv.org/abs/0912.3967

Any references to the work on using slime to mimic the UK rail network that you mentioned? The best I could find was the following from http://www.springerlink.com/content/7tw4745823645128/

"In practical terms such a process may also be witnessed in the evolution of real infrastructure networks, such as British railways following the Beeching reviews in the early '60s [8,9]. In these reviews, the flux along various routes was measured and routes with too low a level of traffic, mainly branch lines, were targeted for closure. At the same time, major routes were strengthened to cope with the expected source-sink relationships for both passenger and freight traffic. Interestingly, the reports focussed on efficient rather than any explicit consideration of resilience, which may explain the sensitivity of the current UK rail network to disruption."

Where: [8] British Railways Board: The development of the major railway trunk routes (1965) [9] British Transport Commission: The reshaping of british railways - part 1: report (1963)

Quite. This'll be an awesome addition to the python toolbox when a diagnostic tool is built around it.

Just in case anybody else is new to jython and wants to give Steve's HTML indexing demo a go:

  $ mkdir google-indexer && cd google-indexer
  $ wget http://bugs.jython.org/file756/google-indexer.zip
  $ unzip google-indexer.zip
  $ svn co https://jython.svn.sourceforge.net/svnroot/jython/trunk/jython
  $ cd jython
  $ patch -p0 < ../google-indexer-patch.diff
  $ tar zxvf ../google-indexer-newfiles.tar.gz
  $ ant jar

And then (following the suggestion in the top of the HtmlDemo class - see src/org/python/indexer/demos/HtmlDemo.java for how to do this on the whole stdlib)

  $ java -classpath ./dist/jython-dev.jar:./extlibs/antlr-runtime-3.1.3.jar:./extlibs/constantine.jar org.python.indexer.demos.HtmlDemo /usr/lib/python2.4/email

This will produce a set of files in html/. Use a suitable browser to view

  $ google-chrome html/Message.py.html

The main 'problem' is that you'll still require an MPEG licence for encoding and decoding. Once you've bought one and abide by the usual LGPL rules (don't claim ownership, make source & changes available if distributing) then there shouldn't be any more commercial issues than, say, using Linux.

video playback and compression is sufficiently cool, and could benefit from optimisation. Have a look to see if any help is needed in the ffmpeg tree at the moment.

I've had good experiences of using DKMS under Debian for 3rd-party proprietary driver modules that recompiles as necessary when updating to a new kernel.

Ah, they must be fans of Peter F. Hamilton. I wonder if they have they started growing Bitek yet?

A sysadmin friend of mine swears by xapply - although it is largely a BSD-only application (and tricky to build on linux, to say the least) it appears to have been the inspiration for xargs's -P option.

We use an absolute minimum in terms of packaging (#) - after all, we don't need to don't need to go out of our way to make it easy to re-build. Packages are mostly C/C++ and python apps, so fortunately none of the extra issues with Java packaging.

Oh, and dependencies are great.

(#) Link has gone now, but available at http://web.archive.org/web/20060925094756/http://www.kclee.d...

We use puppet for configuration that varies between systems, but otherwise bundle our software as debian packages so just need to run 'apt-get dist-upgrade' per machine. Separate private repositories for testing/staging/production sets of the packages.

Sorry, I would really be using a proper RFC 2104 HMAC implementation (eg. python's hmac module).

So, is there much to be gained from encryption anyway? If, as the candidate, I suggested sending a cookie as 'userId=39493&role=user&timestamp=1414919&hash=<sha256-of-key-with-data>' then would I lose brownie points?

I assume my hash comparison function is constant time (eg. XOR(a[x],b[x])==0), rather than comparing of char-by-char.

No, that's easy. It's a shower in french.

Right?

It (Basecamp) is simple enough that our clients can use it. Enough said.

It's only being suggested that Rails ties your website structure to your internal database model more than Django does, and that might be less ideal for your users.

At least one of those loops in the 2-loop version should be backwards... :)

Less clear-cut than the future plans for the database servers are those for Sun's ZFS and Oracle's BtrFS. Are they likely to continue development in parallel, or might the licence on ZFS be changed and development merged?