At one point it was definitely not so deep... carriers were literally looking at the IP TTL and seeing whether it was a recognised value from the phone or a few hops less than one of the common defaults, in which case it was considered tethering traffic.
You could spoof it by finding out your mobile's TTL, overriding the TTL in the connecting device to be one higher than the mobile.
Totally agree with you there, as much as I love to hate non-transferability, revokable licenses, permanent VAC bans on accounts that got hacked, I still find Steam the most convenient path to "owning" games in one place.
The Linux work done for Steam Deck is fantastic and I do credit their efforts with inspiring others to work on similar projects that extend and complement what Valve achieved. Much of the hard effort did go into Windows games on Linux before Valve looked at it; everything the WINE project, Codeweavers did, gaming via Lutris since 2009, however Valve have definitely been a force multiplier.
Trust is earned and I think Valve are doing pretty well on that front, especially when you look at the differences to other PC stores, Ubisoft, EA, and to some extent Epic. GOG and Itch are very different beasts.
To some extent I miss the time where Steam was totally curated, you had to make an impact to get your game on the platform, back before it was a free-for-all of shovelware and low-effort slop. Occasional controversies aside, at least on Steam the tools / marketing funnel are there to keep the popular games at the forefront of the store whilst also being fairly open to allow devs to publish without being the chosen one.
Is there a danger of doing to games what Spotify has done to music? Maybe, but I reckon the super deep-discount sales have calmed somewhat and are happening later in game's long-tail part of the lifecycle or used as promo for sequels.
There are plenty of publishers that choose to mainly avoid going that route, often the traditional established publishers with console outlets they don't want to cannibalise, for example Sony and Konami.
> Is there a danger of doing to games what Spotify has done to music?
I think such business model ultimately doesn't scale well for games (several million-dollars production budgets sharing minuscule pieces of a ~$20 all-you-can-eat subscription pie).
Microsoft always knew this, they didn't try to win the market, they tried to subvert the business model, probably expecting the industry as a whole moving towards it -- which didn't happen at all, at least not yet.
Simple math would prove this. There's no way acquiring half the good studios in the world and make them release flop after flop was a break-even operation. It's several orders of magnitude behind.
Most of the market talks Nintendo, Sony, XBox, Apple Arcade, Android.
Exactly because they aquired half the good studios, they happen to be one of the biggest publishers, people forget some of those studios keep using their own branding instead of anything Microsoft, and it would hurt Steam if Microsoft decides all those studios would pull out of it.
Microsoft moved to a subscription service because they botched the launch of the Xbox One, with users accumulating digital libraries on the PlayStation, and that failure is something that has continued to drag them further and further down.
We use Barman inside Kubernetes via CloudNativePG's plugin, as it is the default backup plugin.
Barman has always been solid for backup and restore, however configuring backup in CNPG is a little more interesting - WAL limits need to be set carefully or you just end up filling WAL volumes and the database becoming unavailable.
> WAL limits need to be set carefully or you just end up filling WAL volumes and the database becoming unavailable.
This is true. For anyone getting alarmed that this is due to a bug in PostgreSQL, it's not - it's PostgreSQL protecting the customer from attempting to write data that it cannot durable commit - "I am going to go unavailable because I don't have enough space to save more data".
There are multiple ways to handle this, the easiest, most hands on way is to keep a monitor and alert that watches the WAL size like a hawk and then alerts OPS the moment it breaches a threshold.
Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which has obviously resulted in some technical debt. The issue you mentioned concerns our decision not to integrate pgBackRest into CNPG's core, as we aimed to develop a pluggable interface (CNPG-I).
As a community, we have decided to support volume snapshot backups and offer the Barman Cloud plugin to ensure we provide the same level of service. Our aim is to encourage other organisations or developers to create plugins for their preferred backup solutions.
Currently, as maintainers of CNPG, we must concentrate on the core capabilities and allow the ecosystem to grow with both community and, potentially, commercial solutions based on CNPG-I.
Great to see you posting on HN! I still remember making the decision to replace Crunchy Data PGO. CNPG was newer and smaller at the time, so maybe riskier, but seeing the way your team had responded to issues, had a real engineering mindset and clear knowledge of how PostgreSQL should be operated made it an easy choice!
Thank you for your efforts, I hope the balance of commercial and community works out well for you, the product is great.
Completely understand your motivations considering the lineage, and I appreciate that you guys put in the effort for the backup plug-in system. I think you guys made the right choices for that project. I appreciate it much more than the Crunchy k8s project which didn't have open images.
I was definitely hoping that a pgbackrest plug-in would mature for cnpg, but I didn't realize there were troubles on the horizon for that project.
The way I read that issue and the linked discussion was, that pgBackRest handles a lot of details itself that's otherwise handled by Kubernetes. Hence, a lot of functionality in pgBackRest is not only redundant but incompatible with how Kubernetes CSI could be used to provide incremental and differential backups. Hence, Barman and `barman-cloud` plugins are a better, natural fit for a Kubernetes environment than pgBackRest.
I remember switching from Win95 to NT4.0 just to be able to use SoftICE properly under Windows without all the stability problems, it was an incredible time! SoftICE felt like absolute wizardry at the time.
Did you use SELECT FOR UPDATE at all, or just never had to update dependent data? If the complex operations are implemented using stored functions / procedures then the a transaction is implicit.
If the data is fairly straightforward like just one-to-many CRUD with no circular references, you would be able to do it without transactions, just table relationships would be enough to ensure consistency.
Yeah, I couldn't even get the damn thing to work reliably when it was new. Oh but you can rest assured that it had no problem exfiltrating all that precious data of mine about what I was doing, and any other things they could suck out of my Android phone. No way in hell will I EVER buy another Sonos product.
we've got a pair of Sonos One speakers airplay(2?) connected to our Apple TV (recent generation): the sound is excellent but connection over airplay regularly is dropped, which might be Apple's doing, since they may well favor device testing with homepods. it drives some here to anger...it is a pisser because the sound quality is great.
I noticed Sonos speakers are featured in some upscale cars now, Audi for example.
There is no .NET Core or .NET Framework since .NET 5.0 in 2020. Maybe you mean ASP.NET Core, but then there is no ASP.NET Framework so the comment still does not make sense to me.
The vulnerable component is ASP.NET Core, which did not change name when .NET dropped the Core name to distinguish it from legacy ASP.NET.
--- edit: cut here - the sentence below is incorrect! ---
If somehow you were still using legacy ASP.NET / Framework 4.8 etc, you have much bigger problems - legacy ASP.NET has been unsupported since 2022 so will definitely not be receiving security updates.
> If somehow you were still using legacy ASP.NET / Framework 4.8 etc, you have much bigger problems - legacy ASP.NET has been unsupported since 2022 so will definitely not be receiving security updates.
There are plenty of apps out there were there is no feasible upgrade path to .NET Core / .NET 9, so I imagine MS will continue to support these for a very long time. Note that the VB6 runtime is still supported in all Windows operating systems: https://learn.microsoft.com/en-us/previous-versions/visualst...
Yes, you're right, the last sentence is definitely a mistake on my part, I should have written less! Thanks for the links, paulirwin's sibling response is helpful too.
We had code using WCF and AppDomains that were always out of scope for .NET Core. WCF has a Core replacement now that is not quite one-for-one but AppDomains will never be supported in .NET Core / .NET 5.0+ and would indeed have to stay on 4.8 / 4.8.1 if they were still running.
Yes, you are right, if you are on 5.0+, however the 4.x stuff is definitely out of support.
Sorry, I did not know they had actually brought non-Core ASP.NET forward into 5.0+, but it makes sense given how much of .NET Framework they continued support for and how much ASP.NET and Forms stuff is still around in enterprise with no budget for bringing it forward.
Totally agree with breaking the chain though, we moved to Core around 2.0 and never looked back, as an ecosystem it is so much better.
> however the 4.x stuff is definitely out of support [...] Sorry, I did not know they had actually brought non-Core ASP.NET forward into 5.0+
None of this is true, you've gotten yourself very confused. The only real change with .NET 5 was the "Core" name being dropped and the Mono runtime being merged in. .NET Framework 4.x is still around and is still fully supported for legacy applications.
Yes, there is, because Microsoft naming sucks, and making the distiction between .NET Core and .NET Framework is the only way to actually explain modern .NET to most folks without background on .NET.
Additionally the mistake to rename .NET Core as .NET is the main reason many people still think .NET is Windows only.
Well they did have a valid reason for a rename, .NET 5.0's announcement coincided with discontinuing Mono and Xamarin, and uniting the non-Windows .NET flavors under a single platform. They also planned to iterate more rapidly and add APIs beyond .NET Standard.
But yes, choosing ".NET" as the new name was a bad idea, since now when someone says .NET you have no idea if they are referring to the modern runtime, or its various generations collectively.
I, for one, think dropping the "Core" suffix (absolutely dumb naming) was the right thing. Yes, it might have created some confusion with the old .NET aka .NET Framework but I hope it's temporary. It's been five years of .NET-no-suffix and nine of it being cross-platform. At some point people should just educate themselves and stop thinking that .NET is somehow Windows only.
Good luck with that, the .NET team keeps referring this is a recurring problem trying to get new users that rather pick something else for their startups or teaching curriculum, just go listen to .NET podcasts where well known figures got interviewed.
Ignoring CR is often how two systems end up parsing the same file differently, one as two lines the other as a single line.
If the format is not sensitive to additional empty lines then converting them all CR to LF in-place is likely a safer approach, or a tokenizer that coalesces all sequential CR/LF characters into a single EOL token.
I write a lot of software that parses control protocols, the differences between the firmware from a single manufacturer on different devices is astonishing! I find it shocking the number that actually have no delimiters or packet length.
Why would ignoring CR lead to problems? It has nothing to do with line feeding on any system released in the last quarter of a century.
If you’re targeting iMacs or the Commodore 64, then sure, it’s something to be mindful of. But I’d wager you’d have bigger compatibility problems before you even get to line endings.
Is there some other edge cases regarding CR that I’ve missed? Or are you thinking ultra defensively (from a security standpoint)?
That said, I do like your suggestion of treating CR like LF where the schema isn’t sensitive to line numbering. Unfortunately for my use case, line numbering does matter somewhat. So would be good to understand if I have a ticking time bomb
At the very least Windows Update can offer you two versions, a stable version of the driver and a newer but potentially less stable version through the "Optional Driver Updates" page in Windows Update.
True, it has never been in an HTML standard, however it was definitely a documented part of early HTML.
The blink element was in Netscape Navigator's HTML dialect in 1993/94, when early HTML was still just hitting IETF RFCs / DRAFTs, you can find blink in the Netscape HTML developer documentation from just after that era, DevEdge. It was never in NCSA Mosaic, the other big GUI browser of the era.
Later on in the process of being standardized, when it was more W3C than IETF albeit still mainly the same people, Netscape agreed to drop blink from the proposals if Microsoft dropped marquee, so in that sense yes, it was never in a standardized version of HTML, but many tags in active use at the time were never in a standards doc.
You could spoof it by finding out your mobile's TTL, overriding the TTL in the connecting device to be one higher than the mobile.