If it's a DCP, it's a HDD or SSD with a non-standard proprietary interface, i.e. not SATA.

Commercial editing software like DaVinci Resolve and Premiere Pro have encryption as an option on the output stage.

You opt to encrypt the contents, and generate a decryption key. That key can be unlimited (which kind of defeats the purpose), or you can pin it down to a specified window, e.g. 20260801 00:00 to 20260804 23:59. And when it's released commercially it also allows you pin it down to a particular server connected to a particular projector.

DCPs use 128-bit AES

https://en.wikipedia.org/wiki/...

All commercial video editing software has the encryption as an option in the rendering/output/finishing sections.

If the producer had done their job, it wouldn't be a password.

A Digital Cinema Package (DCP) has the film on an encrypted hard drive with a proprietary interface, i.e. not your run-of-the-mill SATA socket, and you get a decryption key that only works on your server, connected to your projector, for a set period of time. Every cinema gets a custom decryption key that will only work on their server and their projectors.

It only gets decrypted by the proprietary decoder board inside the projector, you never have a decrypted data stream until the output of the decoder board. And guess what? If you so much as remove an access cover, the projector shuts down and won't power up again until a technician (wielding an access code that you don't have) re-activates it.

They don't need to "handle it". The Digital Cinema Initiative (DCI) has it all worked out.

You want to screen movies, even just to execs and marketing people who will decide whether to take it on (as in this case) ? You buy a DCI-compliant projector, and a DCI-compliant server. The server that I was operating had a fedora kernel but no root access, only user-level access, and a customised GUI interface with controls that only operated the movie screening part, and nothing to do with the operating system*. The server serial number, the projector serial number, the decoding board (inside the projector) serial number all go to identify your system. You get an encrypted film on a hard drive, upload it to storage on the server, then you get your decryption key via email. That key will only work on that server, connected to that projector, with that decoder board, for that period of time. You - the operator - don't decrypt anything. You press buttons to assemble the "show" - your cinema ID, your PSAs and ads, your trailers, and the feature. Then you press "play", and it works.

*custom hardware with no keyboard or mouse access, no Bluetooth, no wi-fi, only a touch-screen. User ID "1" was user, "2" was Technical/Administrative, and you weren't given the password for user "2". Also, the whole system was air-gapped from the internet with ethernet connecting the server to the projector. The server didn't even do the decryption, the film stays encrypted until it gets to the decoder board inside the projector. Uploading the film from the hard drive didn't involve anything like "sudo mount /dev/sdb1 /media/usb1", it was mounted automatically on insertion, then the custom software read and validated the drive, and presented a simple dialog "Obsession (2026) detected, do you want to upload?" with "yes" and "no" buttons. No exploring the drive - which was a conventional HDD with a proprietary interface, so you couldn't just plug it into a regular SATA socket on your PC, only the proprietary socket on the server

It was only a film club setup and not a commercial cinema but I was pleasantly surprised at all this when I was first introduced to it. They must have thrown considerable $$$ to competent designers and programmers to get such a decent system. Of course it could be stuffed up by someone not reading the instructions, but only to the point where a film wouldn't work, and not to the point of crashing the server. or breaking the projector.

Handing over an unencrypted version, and asking "please delete after watching" is simply poor practice.

Every commercial video suite - Premiere Pro, DaVinci Resolve, etc, has output options for DCP format, with encryption, and generate a decryption key with a time window. It's not an expensive add-on that costs big bucks every time you use it.

Then leaving it to someone else to delete after watching. Sure.

I can drink beer and stir soup at the same time.

Seriously though, this is interesting but it shouldn't be news to any sysadmin.

Similar reason for my departure. Some noob was shitstirring and I told them to pipe down (I did NOT use abusive or nasty language), got a complaint lodged against me, resulting in a warning.

Bye bye, never been back.

The "expert install" option on a Debian installer only gives you a checkbox for "standard Debian utilities" - so it's all or none. I don't need LibreOffice, or Gimp, or many others, but my "choice" is to install all of them and remove unwanted ones later, or install none and painstakingly catch up later.

I do remember the much older versions having long checklists but that seems to have gone.

More like "Colossus: The Forbin Project"

Why shouldn't our work schedules adapt, instead of us adapting to work schedules?

If I want to enjoy the extra evening/twilight hours in summer for exercise, BBQ, or whatever, then why shouldn't I be able to start work an hour earlier and finish an hour earlier? I could get to work an hour before customers or other workers arrive and get my paperwork done without being interrupted.

It's possible to stagger start and finish times so someone is at work to deal with customers at all hours. Offer an earlier start and finish time for half the workforce.

And some workplaces don't even need people to be available for customers. If employers weren't so stupidly attached to "nine-to-five, onsite" traditions, they could get people working all sorts of hours.

It might be closer than you think.

The very next /. article (or previous) is an announcement of Microsoft's first Linux distro - Azure Linux 4. Fedora-based.

It's stopping - slowly. AGA-Rayburn have withdrawn solid-fuel cookstoves from sale in the UK, presumably because they couldn't economically be re-designed with catalytic converters.

They're still available in other markets such as South Africa and Australia.

I've got one (Rayburn) but I'm rural and we rarely get inversions, so the smoke doesn't tend to hang about.

It's been the major source of cooking, and the only source of heating and hot water for decades but we've recently had a big solar+battery upgrade so we're starting to electrify a bunch of things that were previously provided by the stove.

I think it's in the hackers' best interests to be honest about this.

If they aren't, and release the data publicly or sell it, or release it in any form after promising to delete it, it tells the world that they can't be trusted, and future ransom demands with promises to delete the data won't be worth the electrons carrying said promises.

They've proved themselves clever enough to crack the security on a relatively secure and trusted platform. They will be looking for the next platform to crack as we speak. When the time comes to make their next demands, the hostages will know that either they can be trusted to delete the data, or not. Being trustworthy means a better chance to be paid $BIGNUM. If their reputation were tarnished, hostages would be less likely to pay, and will take the consequences of exposure of the users' data.

After all, those privacy and security guarantees made when students were required to create accounts, well, no-one is going to be held accountable when the next breach happens, are they? Perhaps some prison terms would be a useful incentive to the next board of management when making decisions on whose software to use.

All those terms and conditions where you have to click "OK" ? Funny how consequences are mostly one-sided - the user. I've never seen T&C where there's any consequences for the other side.