radiowave

I looked in to this a little when Windmill was last discussed here, and the gap you may bump into (as a replacement for Rundeck) is that AFAICT Windmill has no support for executing scripts remotely over (e.g.) SSH and passing the GUI values along as environment variables.

It seems you need a full-blown install of Windmill on each host where actions are to be run.

Putting a file into "that dir" also requires elevated permissions.

(e.g. C:\Program Files\VSTPlugins )

My guess would be the common sense angle, within the context that when someone commissions you to make a pilot, you get it done, because in part, you're trying to demonstrate that you're ready to do the thing for real.

Likewise, 20 years here. I vaguely recall some downtime in the past, so for me this might be the second time I've noticed it.

New Old Stock

Thanks for the reply. Winmill is definitely something that I'll need to take a closer look at, when time permits. I do suspect though that it's going to be a bit too heavyweight to be a direct replacement for Rundeck.

This looks very impressive.

Thinking about it as an alternative to scripted workflows with Rundeck, it seems like the main gap here is getting scripts to run on a specific machine without needing to have set that machine up to run worker processes.

(I could be misunderstanding here, because I haven't spotted anything in the docs that talks about the minimum deployment necessary just to allow a particular machine to run workers.)

Really simple example: there's an administrative command on a mailserver, which can be used to create a new mailbox. I want to make that operation part of some workflow. With Rundeck, I can script this and I just have to make sure Rundeck has ssh credentials onto the mailserver; at execution time it'll deploy the script, substitute in whatever variables, run it and capture the output.

I'm not clear on how I would achieve that with Windmill. Would it involve installing Windmill (or some component of it) on the mailserver, and setting it up as an individual worker group?

It turns out you can find these by going to their github page, and manually trawling through the various subfolders of /MenuOptions/.

Not exactly putting key information front and centre.

The absurdity is striking when you see all this process around DNS in a large org, and then you remember that DNS was invented as a way of permitting delegation of authority, away from the centre.

My vague recollection is that, after DabbleDB, they were working on a new product - some sort of analytics dashboard (?) - they did an early demo of it, and I gather someone at Twitter saw this and thought "oh wow, we need those guys working for us".

I suspect DabbleDB as a product, and its existing user base, was irrelevant in this decision.

There probably are some people using it in the studio, but among the notable features of the 645Z (and the 645D before it) are that it's weather sealed, and shoots in landscape format. So I'd say it's aimed more at field use than in the studio.

Still very happy with my K3 (Mark 1) for its combination of ergonimics, durability and image quality. (Of course, you wouldn't want to use it for video. Picking horses for courses.)

Ah, as if raked into the sand. Brilliant.

Same in the UK for £100, and also for driving at 1oo mph.

Ah, it does indeed. The dangers of skimming. Thanks for the correction.

I remember learning a great deal from the SoundOnSound article, and am now only very slightly shuddering at the fact that it was almost twenty years ago.

One interesting point that neither article seem to cover (at least based on me rapidly skimming through them just now) is: how do you know whether you're in a source/sink regime or a transmission line regime?

The answer tends to take the form of a "percentage rule": if the wavelength of the highest frequency that you care about is more than 'x' percent of the length of the cable, then you better start treating it like a transmission line. I've heard of values of 'x' ranging from just a few percent (for PCB tracks carrying logic signals) out to about 20% (for location sound recording for TV & movies, back when the recording would be to analogue reel to reel, and you might be reluctant to move the recording equipment up near the action.)

An interesting complicating factor here is that much of the UK's installed base of CCTG stations were built during the 90s with the intention of replacing many of the smaller coal-fired stations, which would typically be doing 2-shift operations (i.e., day and evening). Now, those CCGT stations are increasingly used to counterbalance renewables, and (as you point out) are now running on much shorter cycles than they were designed for.

A report from a few years back (which I'm afraid I've utterly forgotten the source) examined the data on this, and argued that as a result of this changed pattern of use, these CCGT stations were now not achieving nearly the kind of efficiency figures they were designed for, which from a carbon point of view is not good news - we might still be emitting lots of the stuff, but just not getting as much practical benefit from it as we used to.

Now, I'm not meaning to suggest that this is a disaster, or that is somehow invalidates the entire of concept of renewables, but it does point to the need to be careful about what we take to be a useful measure of progress - and that merely the quantity of supply to the grid in GWH isn't necessarily it.

And the article under discussion here is of course picking away at another strand of this same idea - when we connect these generators together, it gives rise to system-level effects, and we need to be thinking about the outcomes, both beneficial and harmful, in system-level terms as well.

(Edited for spelling.)

Seconded. I hadn't heard that he'd gone.

Similarly, the past situations where I've wished I had lens tilt available (to give the appearance of greater depth of field), were I taking those shots today I'd probably be looking at using focus stacking instead.

The only option that Postgres's materialized views give you is to "refresh" the view, meaning: re-run the query used to define the view, fetching an entirely new dataset, and use that to replace all the existing data in the view.

There's no facility for deltas, or any other way of propagating changes.

Edit: And to answer your original question, yes you can absolutely base the materialized view on data obtained from a foreign table.

Never tried this with RDS, but it's entirely possible to use postgres_fdw to interact with a foreign table on another postgres server, where you might have more choice about what extensions you run.

I'm doing this right now because I have a postgres installation that it's not yet convenient to upgrade beyond v12, but where I'd really like the benefit of the recently-improved JDBC FDW, which requires at least v13.

AFAICT, the diagram is just there is illustrate the differences between the types of vdev. It doesn't represent a sensible configuration, nor is it what the rest of the article is talking about actually doing.

I've been running ZFS continually since about 2009, currently using its replication as a major part of the disaster recovery strategy for my employer, and in the intervening time having been through a number of disk failures, controller failures, etc.

Just chiming in here to say that I endorse every aspect of the answer that 7e has given you.

In audio production, the relevance of 32 bit audio is that it's using the same 32 bit float representation of the audio that most of the signal processing stages are also using. In contrast, when people talk about 16 or 24 bit audio, they are customarily referring to an integer representation.

In principle, every time you convert from the 32 bit float back to 24 bit integer, there's an opportunity for a careless human to screw up the scaling, and throw away some of the available integer range. Rinse and repeat until you have an audible problem.

So this forms the basis for an argument in favour of keeping the audio in a float representation for as much of the production process as can reasonably be achieved.

I don't see any benefit in 32 bit representation for delivery of the finished content, but I suppose that if, as part of the production process, you're transferring the audio online between different sites/people/whatever, then having lossless compression that works without having to convert back to integer might be useful.

EDIT: Just read the thing more carefully, and realised that it's specifically talking about 32 bit int, NOT float. So right now, I can't see much practical use for this.

IT guy for ERP customer here.

This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.

(C) - License costs can also play into this partitioning.

Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.

> Do none of the decision makers talk with the people that work for them?

In many cases, no. In part because the people that do the operational work aren't the same people who work for the decision maker.

There's a degree of UI design overlap between the CS-80 and Yamaha's electronic organs of the same period, and it's interesting to think about how this pays off for the CS-80.

One of the defining characteristics of an organ is that the sound of the note tends not to change over time and the keys are essentially just on/off switches. Hence, any kind of articulation you want to get into the sound has to be done by working the controls while you're playing.

You then take a synth which is vastly more receptive to having its sound reshaped in real time, and design a UI for it that encourages this, you get a synth that we're still talking about (and struggling to replicate) 45 years later.

The only ones I know of are the Roland A-80 (somewhat rare) and Kurzweil MIDIBoard (very rare), both circa 1988.

The Gem S2 and S3 (as mentioned by TheOtherHobbes) from around 1992 - these do indeed have poly aftertouch, but neither of them are weighted.

Ensoniq was the company who most consistently used poly aftertouch in their keyboards during this era, but AFAIK only ever on the synth-weight keys. For their models that had weighted keyboards, they would use a keybed made by Fatar which only provided regular aftertouch, not poly.

It's not clear to me that any of the challenges the article addresses could be improved by the use of a clock synchronization protocol, such as PTP - it is not within the gift of application software to modify the audio sample rate clock, nor the display refresh rate.

Beyond what the article discusses, I can imagine long-running audio applications where it might be useful to build an estimate of the rate at which the system time drifts relative to the sample rate clock. Even so, we're still in the realm of the application software having to take these slightly divergent timing sources as given.

On the other hand, changing the length of a varchar column in Postgres is actually changing the type of the table, and if you have any other objects in the database that are dependent upon that type (e.g. views), you'll have to drop and recreate them (and transitively, any views that depend upon those views) in the same transaction where you alter the column. This can easily spiral into a lot of work.

What ended up working during the late 80s and through the 90s were ASICs that could be reused in areas other than just "pure" synthesizers - digital pianos, home organs, PC soundcards (IIRC both Emu and Ensoniq ended up being bought by Creative, the SoundBlaster company).

So this worked out well for those companies that were in a position to do a good job of both the ASIC and logic board development, and also use the resulting technology to address those broader markers - Yamaha being the pre-eminant example. (I agree with the point about the DX7 being a sidenote, but I'd say that all the other product lines that the tech eventually flowed into will have ended up being rather more than just a sidenote.)

Regarding the current market, despite all the retreads, I do think there's more interesting stuff going on than there has been for a long time (certainly in comparison to the analogue synth revival of the 90s), and I hope that manages to continue happening, even as I also kind of hope that the retro-appeal stuff will simmer down a bit.