I can't edit my previous comment (which incorrectly implied that the 3 stations at Droitwitch are going out of the same antenna), but I've done more research and have more information.
Droitwitch LW's antenna uses a T-aerial suspended between two 210m steel masts acting as massive capacitive top-loaded vertical monopole. The signal isn't beamed or shaped, it propagates omnidirectionally and this style of antenna offers _0 dB_ of ERP increase.
Even worse, they're transmitting AM, so the power output dynamically increases with the volume of the analogue audio being transmitted. If you cut off the input to Droitwitch, it'd still be putting out a 500kW carrier wave. When audio is applied the amplitude of the carrier is modulated, so for peak loudness (someone shouting or the loudest spike in music) it can take an extra 50% power to create the upper and lower sidebands - at peak, the Vapotron tubes could be putting out a combined 750kW.
The amplification stage is only ~70% efficient as well, so at peak power it's possible that the site is pulling nearly 1MW from the grid.
--
Compared to a modern UHF DTV transmitter station the differences are wild. The big transmitter near me is putting out 6* DTV MUX's at 174kW ERP each, but that's through a 15dBd UHF array at the top of the mast which gives an obscene amount of gain.
- Mains draw at the wall ~150kW (including cooling and ancillary systems).
- Total TPO (RF energy leaving the cabs) from each of the six transmitters is only ~52kW combined (8.7kW each)
- Output of the combiners after losses of ~0.5dB is ~46kW. We can expect another ~1.5dB of attenuation after forcing it up 300m of waveguide to the top of the tower so we're now sat at a "mere" ~33kW of RF energy going into the bottom of our antenna.
- 33kW with a +15dBd gain gets us to an ERP from the antenna of 1.044 MW.
--------------
Note: Numbers compiled from public sources. All mistakes and misunderstandings are mine. Whilst I do work in a tangentially related industry this is completely out of my area of expertise - in the same way that working as a cleaner at an aeroplane does not mean one knows how to fly or maintain a plane.
> so for peak loudness (someone shouting or the loudest spike in music) it can take an extra 50% power to create the upper and lower sidebands
Some people save energy by turning their appliances off at the plug rather than leaving them on standby. Clearly Radio 4 chose to avoid having Brian Blessed on too frequently instead ;)
Also bear in mind that Droitwitch is radiating 3 different services. Talk Sport (1053 kHz), Radio 4 (198 kHz) and Radio Five Live (693 kHz).
My suspicion is that this means an exciter and a stack of amps per service, which then go through a two stage combiner and out to the antenna. There might even be a pair of exciters and amps per service depending on redundancy.
The combiners (certainly for FM/DAB/TV services) also cause cumulative attenuation as the signal gets combined each time, so even if all 3 are radiating at the same power, the first in the chain might need twice as much amplification to make up for losses.
As far as I know the medium wave services aren’t transmitted from the same antenna as Radio 4 LW, they have separate antenna, albeit with one of them (5 Live) doubling up as one of the support towers for the large long wave T antenna slung between the two large towers on site. Although I suspect the plan would be to move 5 Live to the currently unused Absolute / Virgin antenna eventually so they can demolish the long wave setup.
You're absolutely right and I was flagrantly wrong - Droitwich does use different antennas for the different LW and MF services (though still has to combine the output of two transmitters for the same service to increase the power and offer redundancy).
I was very much getting myself confused with some of their other transmission sites where they take multiple DAB or DTV services, modulate, amplify and combine them and then broadcast through the same antenna.
> Anything in space is more expensive and way harder to do, for a datacenter there is no benefit.
If we pick an extremely fast orbit, then relativity means the hardware will age out (slightly) slower, so I'm sure that'll help with the maintenance issue.
It's the wrong way around though. Ideally we want to speed up our current compute ability not slow it down; if it experiences more time than we do then it can do more. Relative-MHz means my slower hardware becomes tangibly fast again.
General Relativity says mass warps space time, so we need to get these datacentres out of the Earth's gravity well. And the Sun's, and the Milky Way's; out into the deepest void of intergalactic space. The good news is that a maintenance callout is still quicker than some of the earth based DC's I've had gear in, but the bad news is that it doesn't get us much of anything at all.
Special Relativity lets us abuse time with speed (something I discovered as a teenager). Going faster than Earth means we experience less time, so we just need to try and slow down comparative to our home base. The earth is orbiting the Sun at ~30km/s, the solar system is orbiting the centre of the Milky Way at ~230km/s and our local group of galaxies is moving relative to the Cosmic Microwave Background at ~600km/s. We can easily get our DataSpaceCentre up to 1,000km/s or more, so we just need to point it relative to all that movement we mentioned above making stationary relative to the universe. It's completely doable, but (as well as far more variable response times to callouts) only gets us an extra second of compute over a human lifetime.
Fundamentally, we're attacking this problem in the wrong direction. Earth's gravity is comparatively minor, and our piddly ~600km/s relative movement is a tiny fraction of the speed of light. We should be filling The Earth with compute, and then decamping humanity into space and travelling at relativistic speeds. Or put the compute in space and move the Earth into the event horizon of a black hole. You can't do the inverse of Interstellar keeping Earth where it is, the maths isn't in our favour. If everyone lived on (a less moist) Miller's Planet, we'd get 7 years of compute every hour. It puts Moore's Law to shame; the relative MHz are obscene.
There's the obvious problem of communications. I'm led to believe there's issues with radio and light, so this probably isn't a job for fibre. Veritasium seemed to imply a battery, switch, lightbulb and a wire stretching around the globe would light instantaneously, so I'm sure we can come up with a new copper Ethernet standard for low latency over solar distances.
> I think in general the ability to spoof numbers should be banned / controlled.
This has absolutely nothing to do with burner phones and the proposed changes won't do anything to change that.
~5 years ago there was a big push (in the USA) to try and solve it with STIR/SHAKEN but I've not been involved or paid attention since then, so don't know if anything came of it. It's a legitimately hard problem to solve though. Lots of engineering and backwards compatibility technical problems, but also political, logistical and commercial issues are abound. You've also got some turtle issues too; it's attestation all the way down.
> This has absolutely nothing to do with burner phones
That is not correct. There a phone farms operating purely on burner phones / disposable sims.
Even for legit use cases, this path is often way easier/cheaper than go through official channels.
Use cases range from carrier-NAT proxies at < $1 per GB to text message spam.
But... what does your comment have to do with burner phones?
A burner phone is a phone number whose owner is not officially registered somewhere as the owner.
A spoofed phone number is a false declaration that you're calling from number XXXXXXXXXX when in fact you're calling from YYYYYYYYYY.
You might notice that there is absolutely no relationship between these two ideas. You can be registered and lie about your phone number. You can be unregistered and not lie about your phone number.
>>> I think in general the ability to spoof numbers should be banned / controlled. Someone from India should not be allowed to call me with a caller ID from Mayo Clinic.
>> This has absolutely nothing to do with burner phones and the proposed changes won't do anything to change that.
> That is not correct. There a phone farms operating purely on burner phones
This is total nonsense. A phone farm that doesn't spoof caller ID isn't presenting false caller ID.
Except zvols present as real-live block devices that can do block-device things instead of regular-file things, and that's important for some stuff.
But AFAICT, iSCSI targets on Linux are not one of those things. They don't care; they work the ~same whether backed by files or block devices.
And on the performance benchmarks I find that compare performance of zvols-vs-files on ZFS, files usually win.
> Why use zvols?
Probably for the same reasons that people recommended separate disk partitions for /var, /usr, and such as was the case ~30 years ago when I got started with desktop *nix systems.
That reason seemed to boil down to: "If it was good for a Sun/3 in 1986, then it must also be good for a Linux box in 1996." It was a dumb reason.
> That reason seemed to boil down to: "If it was good for a Sun/3 in 1986, then it must also be good for a Linux box in 1996." It was a dumb reason.
ext2 disk corruption, especially on power failure or a crash, was a common threat in the 1990s. Not merely to the point of requiring fsck and a bunch of orphaned files (which was inevitable on an unclean shutdown), but just totally fubar'd, requiring a reformat. The only thing worse was then trying to reinstall Slackware from the floppy disks, at least one of which had a better than even chance of corruption from just sitting in the drawer since the last reinstall, requiring another long night nursing a download over the 2400 baud modem.
I use OpenBSD, and while FFS2 has been far more robust than 1990s Linux ext2, smart partitioning is still warranted, not just for minimizing blast radius, but also for managing backups, etc. I haven't had the chance to use ZFS, and it might be the only filesystem I might consider skipping partitioning for on a workhorse system, but even if you trust the design and code quality of ZFS, it's running unprotected alongside a bunch of horribly buggy kernel subsystems and drivers, so....
You raise an interesting point. Please allow me to enhance it.
It could get worse than reinstalling Slackware, again, from floppies. I didn't get to experience corrupted floppies; I instead had a habit of recycling my Slackware disksets for other purposes after the system was up and running. So any complete re-install started by booting up MS-DOS to run Telemate to start downloading them fresh from Sunsite...again.
But at least it was Telemate, so I could manage files to free up more floppy disks while this process slowly continued at [I guess I was fortunate] 9600 or 14.4kbps. ;)
I don't recall much difficulty with ext2 being fragile (though I can provide horror stories about OS/2's HPFS). If I had issues with it, they didn't leave any scars.
But I accept your correction. It may have been the case that splitting the filesystem into different partitions made sense because ext2 was fickle, and I was just very lucky in deliberately ignoring that advice after the first time I misjudged the partition sizes at install and ran out of space in some directory or other.
Hard drives seemed so small back then. Installing a real OS meant a serious tradeoff in the ratio between user data and system data.
---
Anyway, ZFS. The ZFS way is that it owns the whole disk -- for a long time, the preferred method didn't even use partitions at all. Nowadays OpenZFS does create one partition for itself by default, but it uses the whole disk just the same.
Blast radius is limited by having different datasets (think "filesystem-light"), and read-only snapshots, and easy, consistent backups (if you have a compatible device or service to send them to -- otherwise, it's ~the same backup dance as any other filesystem with snapshots).
It's a different way of doing things, like a subsystem in and of itself. It keeps its own caches and generally wants to be as close to the metal as it can be. Which sounds scary, but meh: Almost everything worth doing gets done with two commands, zfs and zpool, and the syntax has been consistent enough over the years that old documentation from Sun still has value.
I've been using it for most of a decade now and I find it to be ridiculously good. My only wish is that it could be a first-rate player on Linux, but license incompatibilities be that way sometimes.
- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...
But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.
I felt the same way about it as you before I started looking for benchmarks as I wrote my previous comment. :)
After all: Why would zvols exist at all if they weren't superior in important ways?
> it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
It's important to note that additional datasets are essentially free on ZFS; it's no big deal to have lots of them (millions of millions of them is A-OK), and datasets don't have a pre-determined size like zvols do.
Although zvols can also be grown and shrunk, just as files [within datasets] can be.
Both datasets and zvols make the same kind of mess out of zfs list's unfiltered output.
But zvols introduce a new concept, while anyone who uses ZFS is already familiar with datasets that contain files.
I think this part is a wash, and that it comes down to operator preference.
> avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Maybe? Again, the benchmarks I found (hours ago now and tabs long-closed; I'll find more if anyone insists) suggested that files were faster than zvols, which suggests reduced overhead. (It's very possible that the tests I found were naively implemented, but then: It's also possible for any of us to do something naive.)
Anyway, it's interesting to think about.
It seems like the right answer is to test with one's own workload and find the best fit, instead of assume that one way is better than the other.
For its part, ZFS should handle a zvol and a file-on-a-dataset with equal stoicism and reliability.
Sure, I'm not suggesting that they're a good idea to use blindly at this point - I think most people are building on filesystem-based setups so most of the polish is going there.
But that was the original logic.
I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).
I don't know how much better modern drives (and SSDs) have gotten[1], but as someone who started digital hoarding in the mid 90's, on-disk bitrot used to be a massive problem. The amount of my video, audio and pictures that suffered damage was palpable. ZFS offering to fix it was massive selling point and the time and based on personal experience, it delivered.
ZFS also lets you specify number of copies on a single disk. This sounds a bit weird, but as drives suffer block failures far more often than total failures, it's actually surprisingly useful in some situations.
[1] My suspicion is significantly, as storage sizes are now multiple orders of magnitude larger and errors per MB can't have scaled up linearly to match.
> ...before you'd want to change your subscription...
For anyone not in the know, Resolve has an exceptionally capable and feature rich free version. A lot of the AI features (and >4k editing) are locked to the Studio licence which is a one-time payment, but works simultaneously on two computers (including different OS's) and allows upgrades across major versions.
I spent less than $300 on it a decade ago and my licence works fine on new v21 released this week. My least-regretted software purchase in 3 decades.
I was a lightroom user for almost 20 years, and their licensing ridiculousness was enough for me to:
- change up my workflow, avoiding raw so I can use simpler editing processes
- do way less editing
- take way fewer photos
It sucks, but I just can't justify their insane pricing scheme. I've been looking for Linux-capable tools for a while, and Darktable / Rawtherapee are a long way from what I'm after. What you describe sounds like a dream.
This seems like an overreaction that punishes you more than Adobe. There are a number of other tools - until fairly recently Capture One offered perpetual licensing, for instance. Giving up RAW to spite Adobe is like being angry at Microsoft Office subscription pricing and saying you'll abandon word processors and just use a typewriter instead.
I don't have spite for Adobe, that seems like a projection on your part. But I can't justify the purchase, and have adapted the way I take photos as part of that.
It's more like finding the subscription for a CAD program too expensive, and swapping to something more primitive instead. If that offends you, I think you gotta have a long hard look in a mirror some time.
The point is that there are many options, at many different price points including free, that don't involve giving up 95% of the data your camera sensor provides and don't lock you into getting the exposure perfectly right the first time or else.
FastRawViewer, DxO, Affinity, Darktable, Capture One. Those are just the ones I personally have installed. There's also RawTherapee, a number of camera OEM-specific tools, and more.
I looked to see if any of these tools support the hdr gain map export that Lightroom supports, and of course, absolutely none of them do. I can't use these.
Back when Adobe upended their perpetual licensing, Capture One was touted as _the_ alternative and I gave it a try since my new Sony camera's RAW format wasn't supported by the last perpetual-license Lightroom version anyway. And man, coming from Lightroom, Capture One was one of the most horrendous usability experiences I have ever had in a creative tool. Even after keeping on trying for a long time, I could absolutely not find a workflow that worked for me and that wasn't filled with obstacles, pains, slowness, inexplicable UI design choices and illogical workflows that totally broke the creative process. It made me miss and appreciate Lightroom so much. But as a photo hobbyist I couldn't justify Adobe's then-new licensing model anyway and the hobby just dwindled away. I ended up finding other paths to express my creative side instead.
If Capture One still is like this, I wouldn't really be surprised if there's truth to the other comment here claiming that their current owners are trying to offload them.
Well, C1 is still the best. But you need two monitors for a smooth experience. Image on one, tools on another. And it's a breeze. Lightroom is like trying to swim in a pool of mud with tin ankle bracers :D.
Capture One still offers a perpetual license for US$349... it's the option down at the bottom, of course. And they still do discounted upgrade pricing on that, too.
Like all software companies that go down the subscription hole, they do their best to hide it. You literally have to login and click on a bunch of things to get to that point.
And I'm sure this will all change when the new vulture capital fund that snaps it up tries to extract every last microcent of "value" from the brand.
I should also note I jumped ship to DxO as soon as C1 started going down the subscription hole. And frankly, I'm kind of glad they're struggling. I guess they thought they were going to replicate Adobe's "success" with subscriptions without first being a near-monopoly.
Absurd? What's with you folks and your strongly charged language?
Please recommend these "powerful alternatives", because I have explored the space and found nothing that replaces Lightroom in a way that I find acceptable. Please omit Darktable and Rawtherapee as I've already evaluated those.
Yeah that's a good point that I often forget about, thanks.
I wasn't looking for RAW hdr, just plain jane RAW support that handles moderately new cameras. I stayed on with the old Lightroom as long as I could, but a) it didn't handle my new Sony RAW files, and b) new Mac versions made it impossible to run.
I've moved away from Apple, as that was the last thing tying me to it. Photomator might be nice actually, maybe a good reason to dust off the iPad - cheers.
...
Edit: mobile editing has come a long way since I last checked. Photomator seems really great - between this and a desktop-first approach (Darktable / Davinci) I think this solves all my needs. Big thanks for the recommendation.
Great that it works for you. I gave my daughter my old Canon 70D and she needed a way to process pictures. She only has an iPad and I didn’t push her to adobe ^^. She produces great results with Photomator.
I need to do the jump myself to something better. The last update of Lightroom classic runs so damn slow on my Mac mini (M4). Was super annoyed yesterday while working on some pictures.
This is what I've found, sadly. But there's always folks like Arainach in the sibling thread that'll chew you up if you dare complain about the usability of anything OSS.
This is the new version of "GIMP is better than Photoshop", it seems.
It's a bit convoluted to get to but you can also "rent" a license for $30 a month through Blackmagic Cloud. As with many, I'm not a fan of subscription licenses but it was valuable for me to use for a month to evaluate if the Studio features warranted the investment in the permanent license. Specifically some of the Fusion effects are Studio only.
That’s quite reasonable. Props for them for doing it.
Without updates included, buying a lifetime license nowadays feels more like a subscription which expires as soon as your OS upgrades instead. It also creates a lot of friction with different file formats when you try to collaborate. companies know how to exploit this to force you into subscriptions.
I regret spending money on multiple pro versions of Hitfilm in hindsight. I found Resolve very daunting as a beginner and Hitfilm's layered editing felt easier at the time. But looking back I should have just spent it on Resolve pro license. I stopped using Hitfilm way before my last license expired just because Resolve just felt better once I got a hang of it.
iirc, the OpenFirmware boot image was larger than the equivalent BIOS image - I've got half a memory of resoldering ROM chips on ATi cards so they could be cross-flashed to work in G3/G4 PoweMacs.
If you enjoy this age of SciFi and don't mind radio drama rather than film, then X-1 is well worth checking out. It's a 1955- radio drama with a different short story each episode, quite a few stories from well recognised authors.
Droitwitch LW's antenna uses a T-aerial suspended between two 210m steel masts acting as massive capacitive top-loaded vertical monopole. The signal isn't beamed or shaped, it propagates omnidirectionally and this style of antenna offers _0 dB_ of ERP increase.
Even worse, they're transmitting AM, so the power output dynamically increases with the volume of the analogue audio being transmitted. If you cut off the input to Droitwitch, it'd still be putting out a 500kW carrier wave. When audio is applied the amplitude of the carrier is modulated, so for peak loudness (someone shouting or the loudest spike in music) it can take an extra 50% power to create the upper and lower sidebands - at peak, the Vapotron tubes could be putting out a combined 750kW.
The amplification stage is only ~70% efficient as well, so at peak power it's possible that the site is pulling nearly 1MW from the grid.
--
Compared to a modern UHF DTV transmitter station the differences are wild. The big transmitter near me is putting out 6* DTV MUX's at 174kW ERP each, but that's through a 15dBd UHF array at the top of the mast which gives an obscene amount of gain.
- Mains draw at the wall ~150kW (including cooling and ancillary systems).
- Total TPO (RF energy leaving the cabs) from each of the six transmitters is only ~52kW combined (8.7kW each)
- Output of the combiners after losses of ~0.5dB is ~46kW. We can expect another ~1.5dB of attenuation after forcing it up 300m of waveguide to the top of the tower so we're now sat at a "mere" ~33kW of RF energy going into the bottom of our antenna.
- 33kW with a +15dBd gain gets us to an ERP from the antenna of 1.044 MW.
--------------
Note: Numbers compiled from public sources. All mistakes and misunderstandings are mine. Whilst I do work in a tangentially related industry this is completely out of my area of expertise - in the same way that working as a cleaner at an aeroplane does not mean one knows how to fly or maintain a plane.