Tl;Dr the protocol requires there to be trusted token providers that issue the tokens. Who do you suppose are the trusted providers in the Google and Apple implementations? Google and Apple respectively, of course. Maybe eventually there would be some other large incumbents that these implementers choose to bless with token granting right. By its nature the protocol centralizes power on the web, which would disadvantage startups and smaller players.
Private State Tokens are Google’s implementation of the IETF Privacy Pass protocol. Apple has another implementation of the same protocol named Private Access Tokens. Mozilla has taken a negative position against this protocol in its current form, and its existing implementations in their current forms. See here for their blog post on the subject, and here for their more in-depth analysis.
It’s likely CentOS 7.9, which was released in Nov. 2020 and shipped with kernel version 3.10.0-1160. It’s not completely ridiculous for a one year old POS systems to have a four year old OS. Design for those systems probably started a few years ago, when CentOS 7.9 was relatively recent. For an embedded system the bias would have been toward an established and mature OS, and CentOS 8.x was likely considered “too new” at the time they were speccing these systems. Remotely upgrading between major releases would not be advisable in an embedded system. The RHEL/CentOS in-place upgrade story is… not great. There was zero support for in-place upgrade until RHEL/CentOS 7, and it’s still considered “at your own risk” (source).
He was a raging alcoholic who hid his illness from the medical professionals who examined him as part of his Super Size Me “experiment.” A lifetime of booze did way more damage than 30 days of McDs possibly could.
This seems a lot more plausible to me. Exit wounds tend to be pretty gory.
Jesus, what a bunch of needless “security”
I disagree with this part. Ticket theft is an actual issue, there are lots of ways to get a copy of someone else’s barcode and either use it before they do or (more likely) sell it to someone else online. TicketMaster’s marketing is talking up the increased security to distract from their true purpose, which is of course to find more ways to take more money from fans. Of course it’s debatable whether the increased security is worth the decreased convenience for ticketholders. That is the inevitable tension when it comes to security, where any increase in security always incurs at least some cost in terms of convenience.
This is all for personal data mining.
TicketMaster might be selling user data, but I don’t think that’s their main aim. They want control of the resale market so they can take a cut when tickets are resold. Note how they don’t allow direct transfers between two mobile wallets, they only allow transfers using their app. That’s so they can monitor transfers. If they see someone transferring dozens or hundreds of tickets to many other TicketMaster users then that person is likely reselling and they can clamp down on their account. TicketMaster’s true intent is to force all resales onto their ticket marketplace, because that’s where they get to take a cut of resales.
Oh yes, I don’t mean to absolve them of any blame. They treated it as an expensive lesson, which is probably the best way for them to process it.
Also while TicketMaster is going to sell this as being an “enhanced security” thing, it’s pretty obvious that increased security is only a side benefit for them. Their angle in this is getting more control over the tickets they sell. As long as there are many people who want to go than can physically fit in a venue, there will be a reselling market for event tickets. TicketMaster wants to take a cut of these downstream transactions.
While the security of rotating barcodes does hinder outright scams, mobile wallets normally allow wallet users to transfer items like tickets to another user if the ticket issuer allows it. TicketMaster does not allow this for their tickets, of course, because it could allow someone to resell tickets while cutting TicketMaster out of the transaction. Currently TM allows transfers using their app, but I’m sure they monitor usage of the feature and clamp down on anyone transferring many tickets. In other words if you try to resell in bulk without using TicketMaster’s own platform (where they get to take a cut), they drop the hammer on you.
The reason you can’t use screenshots or printouts is because they’re now using rotating barcodes. Much like the rotating codes in an authenticator app, the number values behind the barcode are changing on some regular cadence. Only the most recent barcode value is considered valid.
The only other option is to use a mobile wallet, but that prevents me from sending my friends their tickets, since I purchased them all together.
Some ticket sellers allow you to transfer tickets from one wallet to another wallet, but of course TicketMaster isn’t one of them because they’re fucking TicketMaster. What TicketMaster does allow is transfers from one TicketMaster account to another. Of course then everyone needs to have a TicketMaster account, needs to have the app, etc. It’s either that or leave all the tickets in your app or wallet and go in together. If you tell the door person “I have the tickets for these X people,” they’ll be able to handle that.
Yes because the security of barcodes and screenshotted tickets were such a huge problem before.
I think what you just described is actually a problem. Friends of my parents were visiting somewhere, bought tickets to a show from a reseller, met up with the seller (normal looking guy, no red flags, gave some plausible story why he was selling) and paid cash for printed out tickets with barcodes. Printouts looked legit, dates on the printouts were correct, etc. Went to the doors, tried to scan their tickets, got told that unfortunately they’d just been scammed. The impression they get from the box office worker is that this sort of bad news is something they’ve had to deliver frequently. Anecdotal, but I doubt those friends of my parents were the only ones to get scammed in this way. TicketMaster still sucks as an organization but the extra security of rotating barcodes does serve a legitimate security purpose, just like the rotating security codes generated by an authenticator app.
Airlines have recently been having problems with stowaways using screenshots of boarding pass barcodes or QR codes too. Such stowaways should get caught before departure by passenger headcounts or boarding ID checks, but clearly there are gaps or breakdowns in these procedures because some of these stowaways are getting caught at the destination. Others may have successfully flown for free. If it keeps happening I bet we’ll see rotating barcodes come to mobile boarding passes too, if that hasn’t already happened.
I’m sure there would be a way to do this with Debian, but I have to confess I don’t know it. I have successfully done this in the past with Clover Bootloader. You have to enable an NVMe driver, but once that’s done you should see an option to boot from your NVMe device. After you’ve booted from it once, Clover should remember and boot from that device automatically going forward. I used this method for years in a home theatre PC with an old motherboard and an NVMe drive on a PCIe adapter.
Containourboros!
You can do this with custom formats. You’d want to create a custom format that gives a score if the file is below a certain size threshold (say 1.5GB per hour), then add minimum custom scores to the release profiles you use (e.g. Bluray 1080p). You can also add custom filters for release groups that prioritise file size. YTS for example keeps their releases as small as possible.
Indie game developers have been getting hit with chargebacks for years. To be clear, not every key on the resellers’ sites are illegitimate. There are lots of legitimate reasons to want to resell a key, for example a key for a game you’re not interested in that’s received as part of a Humble Bundle or something. However when someone uploads 1000 keys for a newly launched game, it’s highly unlikely that those are legit but the key reseller sites don’t ask any questions about where the keys come from. The resellers just want to sell the key and take their cut, and they don’t give a shit if it was purchased with a stolen credit card because the original key seller is the one left holding the bag when a chargeback occurs.
Key resellers are really, truly awful. In many cases the keys are purchased from legitimate sites using stolen credit card numbers. The key resellers plead ignorance as to where the keys come from, but it’s an open secret at this point. If you don’t want to pay the Steam/Gog price, piracy is less awful because you won’t be fueling a criminal enterprise and there’s no chance your Steam/Gog account will get a stolen key revoked.
Credit card fraud and software keys actually ends up being paid for by the rest of us. Fraudulent transactions and chargebacks lead to higher merchant fees, and those costs end up getting passed on to legitimate purchasers.
To be honest, I didn’t either but I wanted to know where all these names come from. So I did some Googling and that’s what I found. Apologies if I’ve mangled anything, but I think I got the broad strokes right. Etymology (the study of the origin and evolution of words) is neat!
Essex comes from Old English Eastseaxan, literally “East Saxons”. In other words, this is the part of England that was invaded/settled by the Saxons and they divided their lands into east, south and west regions, plus a middle region (middle Saxons, modern-day Middlesex).
There’s no Norsex because at that time the lands to north of Saxon territory were held by the Angles. They also divided themselves into East Angles, South Angles, etc., but those names don’t seem to have survived into the modern day. Interestingly though, the Kingdom of East Anglia was divided into “North Folk” and “South Folk”, which is the origin of the modern-day names for Norfolk and Suffolk.
If you’ve heard of the Anglo-Saxons, yeah, that’s these guys, the Angles and the Saxons. The Angles came from parts of modern-day Denmark, the Saxons from parts of modern-day northern Germany. They shared a lot of common Germanic culture but were also rivals.
Oracle is shit because they use Red Hat works, providing contract on top of it… and only add UEK as … “better option” …
That’s something they were allowed to do. It’s something everyone was allowed to do. FOSS means free and open source for everyone, even people and organizations you don’t like. Otherwise it’s not really free (as in freedom), now is it?
Also, the “contract on top of it” is this license, which is a pretty short read. In my view it’s a very inoffensive license compared to Red Hat’s coercive license.
Also also, they’re forking Oracle Linux from RHEL as of 9.3, so they’re won’t be “taking” from Red Hat in future anyhow.
They (oracle) do contribute some on mainline kernel, but by making RHEL copy paste and only add UEK and their product… ugh… I don’t know.
It drives me nuts when I see people imply that Oracle was somehow “stealing” from Red Hat by creating a downstream distro. It’s not theft when the thing being taken was free and open source! So Oracle copy-pasted RHEL, made some changes and redistributed it. So what? That’s something everyone was allowed to do, as long as they didn’t violate the open source license while doing it. Oracle isn’t violating the open source licenses, the sources are freely available, so why should I fault them for doing what they did?
I think you’re also overlooking how much Oracle Linux actually benefited Red Hat themselves. By making Oracle Linux a downstream distro and testing all the Oracle software on it, I’d argue that Oracle actually made RHEL more valuable by increasing the number of enterprise workloads RHEL could support. Yes, a customer could theoretically get support from Oracle instead of Red Hat, but hardly anyone actually did that. I see real-world Oracle Database installs every day and the majority of them are on Red Hat Enterprise Linux proper. Very few are on a downstream. Every one of those RHEL installs is a paying Red Hat customer.
Oracle didn’t do all that out of the goodness of their hearts of course, they did it because their customers wanted to standardize on one OS and Oracle wanted to sell them database (and other) software. They did it for profit, but there’s nothing inherently wrong with that. Both Oracle and Red Hat profited from that arrangement. Every enterprise Linux user indirectly benefited from the arrangement too, because it meant there was a less fragmented OS ecosystem to build on! But now Red Hat wants to alter the deal, Vader-style, Oracle is forking Oracle Linux, and you know who loses the most in all of this? All of those users who previously enjoyed the benefit of a less fragmented enterprise OS landscape, myself among them. As far I’m concerned, the blame for that lies squarely at Red Hat’s feet.
I was actually kind of hoping for the second option, if only so that it would be Oracle footing the legal bill to establish a precedent. That Oracle didn’t choose this option may indicate that Red Hat’s coercive license wrapper (“if you exercise your open source rights to redistribute, we’ll close your account”) is actually an effective and legal end-run around open source licenses. I don’t want that to be the case.
From a practical standpoint, we believe Oracle Linux will remain as compatible as it has always been through release 9.2, but after that, there may be a greater chance for a compatibility issue to arise. If an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem.
This is the part of the post I find most interesting. Looks like Oracle won’t be engaging in whatever workarounds Rocky Linux and AlmaLinux are using to continue operating as downstream distros of RHEL. Instead, if I’m reading this correctly it means Oracle Linux will essentially be forking from RHEL past 9.2. There were essentially three options before Oracle when Red Hat made their license change:
That they’ve chosen the third options is kind of fascinating to me, and to understand why you’d probably need to understand how enterprise database support works. The Oracle databases I see day to day are massive, and they drive practically all of a company’s core operations. Unanticipated downtime is fucking expensive, so these companies are willing to pay a lot for top-tier support (not like I think Oracle Support is actually good, mind you, but that’s a whole other topic). The DBAs running these databases don’t want to deal with any headaches whatsoever, so they’re only going to install Oracle on approved operating systems. They can’t afford to have Oracle say “nope, sorry, unsupported platform” during an outage.
For a couple decades now, the supported Linux platforms for Oracle Database have been RHEL, SLES and Oracle Linux. Obviously Oracle Linux will remain on that list, and I doubt SLES is going anywhere either (it tends to be popular in Europe), but does RHEL drop off the list in future? Does Oracle think they can actually convert RHEL installs to Oracle Linux installs at customer sites? Or does RHEL stay on the list but become the red-headed step-child? Either way, this feels like an attempt by Oracle to erode the value of Red Hat’s platform. It’ll be interesting to see how it plays out.
I’m all for de-Googling, but… is it possible that Restricted in this context mean those apps have no data usage because they’re restricted from using it? It could be trying to say that the app is restricted, not that you’re restricted.