> 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.
WinCE had a load of weird issues (and looked consistently awful), but moving onto PDAs and even phones running it from a world of Psion and Palm was like stepping forward a century. This might be rose tinted recollections - and helps that it coincided with with the consumerisation of WiFi and Bluetooth - but fond memories. I still can't believe how Microsoft had a surprisingly capable mobile OS years before Android or Apple and yet managed to fail so badly.
All tech enthusiasts at the time remember how amazing WinCE looked on the shelf. The thing that held it back was that it was just a cool technology, but wasn't an actual solution for any problem regular people had.
Regular people didn't need to carry around a pocket calendar or phone book. And most of the people who did -- carried paper ones that were easier to use didn't need charging.
Smartphones didn't get any traction until email started to take off, and Blackberry and Windows Mobile solved a problem by bringing email to handheld phones. And then they remained email devices for people who needed email on the go (business and tech-forward people)
Feature phones at the this time were catering to the two things people did want on the go: music and text messaging. Apple then started the smartphone consumer market by making a music-phone out of an iPod, and the rest is history.
The main problem was, that barely any useful apps existed. In the early 2000s internet connectivity was working well on those devices at some point (Wifi, via bluetooth phone, or integrated). But there was nothing to do with it, except syncing Outlook and some very limited mobile websites.
The only thing those Windows Mobile 2003 era devices were good for: Playing Age of Empires. There was a full featured port of Age of Empires I, and it was really awesome! It worked really well with the pen input.
The big issue with Wince was mobile IE was just an awful browser. I probably was not alone in wanting some 'webtop' gadget, but these weren't it. (In other words, iOS safari really was a killer app.)
A decade or so ago, my partner's cell phone provider was bought by AT&T and the old network was to be disconnected. AT&T's network was incompatible with their existing phone so they were required to get a new one.
The only smartphone they could get for free was a Nokia device running Windows Phone 8, so they picked that.
Their level of technical sophistication was not very high and this was to be their first pocket computer.
It had a fraction of the CPU grunt of my Galaxy S5 so I expected it to be slow and for them to hate it. I also expected to be asked to solve problems with it and help them along with some aspect of it or another.
But there was none of that. It just worked. They never had any questions. Like many people with a pocket computer, they came to use it all the time for things.
I poked at it myself a few times and found the user interface to be very different from Android and IOS, but it flowed well and was always instantly responsive. It was a neat little machine that seemed to perform extraordinarily well.
And despite finding a way to get this kind of positivity from me, a former OS/2 zealot and long-time user of free operating systems, they still managed to completely fuck up the entire operation. It remains the only example of a Windows Phone device that I'm aware of ever having seen someone use in the wild.
> And despite finding a way to get this kind of positivity from me, a former OS/2 zealot and long-time user of free operating systems, they still managed to completely fuck up the entire operation.
Indeed. I've ranted on this a bunch, but tldr; all they had to do was keep making cheap phones that worked surprisingly well and building the install base; but they wanted to focus at the top of market and wm10 was a disaster.
> It remains the only example of a Windows Phone device that I'm aware of ever having seen someone use in the wild.
They had some placement in Scandal or House of Cards, I think. Was pretty weird for me as a WP user to hear the ringtones and see the UI on the shows I was watching. Not a whole lot of market penetration in the US, but pretty decent in lower income countries where something that was very inexpensive and worked enough had legs.
> Lower income countries where something that was very inexpensive and worked enough had legs
As a lower income country citizen who had a Lumia 635, that's exactly how they got me. It was something like 150-160 U$S and at the time, in my country that would've bought me a Galaxy J2 or some other bottom of the barrel phone with a laggy Android UI. In contrast the Lumia 635 was just as compute/memory-starved but Windows Phone could handle it way, way better. My dad even used it into 2019 after I upgraded because it was just there and worked better than any cheap Android phone.
The developer experience of the platform was weird. As someone with (a bit of) C# experience I found XAML+C# way easier to get into than Android's kludgy layout system, but as expected the ecosystem of libraries was just not there, and while it was easy to get a free developer account as a student it was a bit pretentious of Microsoft to expect normal people to pay 25(?) USD for the privilege of publishing in a marketplace of between 0 and 5 users.
Not having the hardware vertical integration until buying Nokia was a big limitation. As was the use of resistive touchscreens, which usually requires a stylus to achieve any accuracy.
CE wasn't too bad. It was nice having mostly the same API as desktop windows, so you can easily cross-test.
I certainly thought the c. 2001 PDAs under the PocketPC brand were absolutely sick. My hot take is that if the US telecom industry had by that year built out a network of good 3G coverage, those PocketPC devices would have of course had cellular capability, and would have sold like hotcakes, and would have become the basis, the ‘trope originator’ if you will, for Mobile computing. What iPhone was in our timeline.
I think what really held them back was that Wi-Fi was only starting to roll out, and outside a hotspot area, the universe of things you might do with one was necessarily quite self-contained. It limited what “killer apps” could be developed, as anything designed for the platform probably needs to be fully offline most of the time.
I don’t know, I remember them being great from a HW point of view (I had an iPAQ 514 and it was mindblowing even without touch and just a tiny screen), but UX wise…
I now have another iPAQ with a stylus and touchscreen, and I’m grateful back then I did not have it nor the mobile version of Age of Empires… it’s addictive stuff and a crazy good port. I don’t remember anything so good on PalmOS 5 (we had a Garmin iQue 3600, with integrated GPS and navigation… also very futuristic).
They were great from a hardware point of view!! I'm just saying adoption was held back, compared to what it was in 2008-2010, because most of the things people lost their minds about in the later era were the always-networked type of things: Fast and accurate texting, web browsing, Google Maps, watching YouTube or Netflix on the bus or as you enjoy your lunch break at work. All those things require Internet and most people who might have (or did) buy an iPaq etc. would have usually not had access to Wi-Fi in most of those places and 3G data wouldn't come around (the US at least!) for a few more years.
We did see Windows Mobile 2G and 3G smartphones a year or two pre-iPhone, though, so maybe I'm full of it and that platform somehow didn't have something else the mass market wanted.
I've watched my work laptop reboot in the middle of installing Windows Updates without prompting me for a Bitlocker key. It seems obvious to even the casual observer that the pin isn't always required.
I don't remember which updates triggered it, but that was September 2015.
From the perspective of the TPM, I have now learned that it is required for it to release the key.
Perhaps those updates didn't really reboot in the traditional sense. If you turn the machine fully off and then back on, and it still doesn't ask for a PIN... now you have my attention.
Bitlocker can be "paused", which really means the key is written unprotected to disk. This can be done by the user, but also happens temporarily during updates that would change bootchain measurements, because those measurements are used by the TPM to decrypt the key (hence changing them would make the key undecipherable).
I can see someone taking advantage of that under the assumption you can get the machine to update while it's powered on (and already unlocked)... but hopefully that's not what they're calling "TPM+PIN is vulnerable too".
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.
reply