The last half year or so went ok, but not being able to stop automatic upgrades is ridiculous. In general I like opinionated software, but sometimes it goes to far.
916 karma · joined May 4, 2012
The last half year or so went ok, but not being able to stop automatic upgrades is ridiculous. In general I like opinionated software, but sometimes it goes to far.
Using words like "slavery" just for added effect is not good style.
Now I am truly at a loss for words
However, I think that just because a person holds a different view on things we should accept that and not disregard other things this person does based on a diverging worldview. This tolerance can of course have boundaries, but these boundaries should be reasonably broad.
Again, I want to emphasize that I find it really great that you took the time to answer here.
In one occurrence we wanted to create a VPC peering between the a database hosted on Timescale Cloud and our Kubernetes cluster hosted on Azure. For this you need to put the Azure resource group name in a form on Timescale cloud.
Turns out our resource group name contained an uppercase character and the form on Timescale Cloud has a (broken) validation that required the name to be all lowercase. We couldn't easily change that name since that would have required us to re-create our production AKS/K8S cluster.
After contacting Timescale support (as a paying customer) the answer was basically: "Well, we require the resource group name to be lowercase, we can't change that, sucks to be you, bye"
We can live without that VPC peering, so we didn't push that further, but there are zero technical reasons for that restrictions and I would bet that its just a broken validation regex in their backend that they are unwilling to fix.
For me it seems like everything except the "Work from Home" forum has disappeared. So its probably just some forum issues.
With my QuietComfort 35 sometimes the A2DP profile is not negotiated and it falls back to HSP/HFP which sounds like a landline in the 90s. Then you have to disconnect/reconnect it and hope it works this time.
Another pair of cheap sports headphones I own just like to pair with everything that is in range if no other device is connected.
And lastly my Sony WF-1000XM3 just never automatically connects to my phone. I always have to manually go into the Bluetooth menu to connect them.
I think there should be some type of conformity certification, not for the implementation of the Bluetooth protocol itself but for how a device has to act in certain scenarios.
It just happens that the usage data collection uses that CDN thus triggering the bug. But you can also encounter it by just visiting any other website served by that CDN.
That way the customer router could tag the VoIP packets as high priority without us having to deeper inspect the traffic. Since it was required by law that a customer could supply their own router this was also publicly documented. However, abuse wouldn't really be feasible because the bandwidth allotted per customer to high priority traffic was rather small.
In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623
Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.
IMHO it should mean that the rate of errors is increased but the service is still able to serve a substantial amount of traffic. If the rate of errors is bigger than, let's say, 90% that's not an increased error rate, that's an outage.
IANAL, but I don't think this law is a relevant factor when picking your hosting provider.
I had the some trouble with MySQL accepting invalid dates (like 0000-00-00) while Postgres rejects such dates. However, there was an option to convert such dates to NULL which saved the day.
Also you have to manually rewrite your views. Since we had a lot and also very complicated views I ended up materializing each MySQL view, manually porting it to Postgres and then comparing the result. That worked quite well.
Each call had two source number: One user provided and one network provided. The user provided number could be set by the caller (within limits). The network provided number was always set by the provider.
A normal callee would see the callers user provided number. The emergency services, however, would see the network provided number.
This worked for PSTN calls as well as for VoIP (via the P-Asserted-Identity header)
My first post is about the fact that even though the planned use case would be 100% compliant to the AGPLv3 license the fear that is associated with that license could prevent such use.
> That makes zero business sense
Purchasing a license in that case while not strictly necessary might be seen as an insurance. So that makes business sense.
In the end though I highly doubt that's whats going to happen. The most likely outcome is that we just get told to get rid of Grafana and use something else.
I think if there would be a possibility to pay money to have what we are doing reviewed by Grafana and be "certified" to be withing what they consider acceptable under the AGPL that might actually be a good option
I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
If you filter out the RFEs (Requests For Enhancement) you find 617 issues. If you filter for only issues labeled as a bug you get 97 results.
The load shedding mechanisms worked, supportive power generation was automatically activated and there was no widespread blackout.
You are right that it appears like there was insufficient capacity at the north-west/south-east separation point and I guess that is going to be investigated but apart from that everything looks like it worked.
It I understand the RFC correctly a client can announce server push support via the SETTINGS_ENABLE_PUSH setting. So if a client chooses not to announce push support it is still standard compliant.
There is an article in the German Wikipedia about this: https://de.wikipedia.org/wiki/IBAN-Diskriminierung
You can put in a complaint here: https://www.wettbewerbszentrale.de/de/beschwerdestelle/sepah...