Re: Only .5% of users affected.
That was 5 percent, this number is a tenth of that
2251 posts • joined 23 Oct 2007
> That's only GPL and in such situations the source must be provided with the software: the requirement predates publically accessible repositories. Yes, even CVS.
GPL only requires that an offer of the source accompany the software
> accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
So you absolutely can ship someone binaries and say "source is available at https//github/foo", or indeed "to request a copy of the source, contact foo"
But, of course, this also means they wouldn't be in breach just because the repo got deleted (so long as they had a copy and could satisfy subsequent requests)
that they were able to assemble a jury at all.
You'd think that Charter's legal representation would have identified that there's noone in the US who's opinion towards them and other cable companies isn't prejudiced by experience...
7.3bn is way too much, but I've no sympathy for them - they clearly skipped employment checks before sending the guy into people's homes, and then ignored red flags during his employment. That they topped it off by sending the victim to collections really is the cherry on top of the turd.
It's not just them though. That the US system allows for a divorce to leave someone penniless and desperate is also a major issue - there are enough ways people can end up like that without the legal system applying disproportionate remedies.
Ironic really, given the disproportionate remedy that's been awarded at the end of the story.
GDPR made it explicitly clear that that was not sufficient.
that the article didn't mention the responses that those tweeting in support got.
Nadine Dorries: Encouraging others to take their own life is what comes under that definition. It’s a huge problem, especially with young people. You really define that as ‘hurt feelings?’
Response: That's already illegal. You can get 14 years of imprisonment. Here's a little info as you appear to be a little unaware: https://www.cps.gov.uk/legal-guidance/suicide-policy-prosecutors-respect-cases-encouraging-or-assisting-suicide
Collins: This is completely wrong @KemiBadenoch - tell me where in this bill there is any provision that requires the removal of legal speech
Response: https://twitter.com/jamesrbuk/status/1547335143597146114 (section 151 4 says: “Harm” means psychological harm amounting to at least serious distress)
Lucy Powell: Educate yourself before you preach if you want to be PM.
Response: basically boils down to: have you actually read it?
It really does seem that most who support it don't understand what it says. Perhaps they're too close to it, and so only see their own interpretation.
Section 151 really is quite bad though (https://publications.parliament.uk/pa/bills/cbill/58-03/0121/220121.pdf), well intended or not, this is not a well written law.
I use a Eufy set up for our cameras - generally rather happy with it.
One thing to watch though, is that the "held locally" thing has its limits, as the HomeBase gets a bit funny if the internet (or the cloud service) goes AWOL.
You can livestream the cameras from the homebase using RTSP, and the cameras are still recording to the Homebase, so technically it is "working" without an external connection, and your recordings are being held locally.
But, you interact with the homebase via an app which relays via the Cloud service (there isn't a web interface or similar on the base station). So, without the internet you can't view recordings, receive notifications or turn off the alarm if triggered.
Your recordings are held locally, but the setup is still relatively useless without the cloud component. Technically, you could feed the RTSP streams into Zoneminder, but the cameras are battery jobbies, so you'd forever be recharging them (or would need to run a usb charging cable to them).
So, although Eufy never hold video from my cameras, the entire solution would still be fairly useless if they shut down their cloud service.
> The leccy company put the direct debit up despite me paying them less, so now they get to cream all that interest off the money I've saved that should be in my pocket! I wont' get that DD money back for at least 12 months
If you're like me and track your reads/usage, you can probably get the DD adjusted.
I've had reasonable success with going back and saying "here's my usage over the last year/2years using your current pricing - you can see our monthly usage averages at x/month, so the DD should be reduced to that".
There was, but that was a little different IIRC.
It was bought from a dealership who had had autopilot enabled so it coukd be demo'd on test drives. It was then sold without autopilot, but they forgot to turn it off initially.
Still a good example though tbh.
It all feels like gouging - if the hardware is installed then presumably what you paid for the car covers it (otherwise they'd be making a loss). There's no ongoing cost to them of you being able to use the heated seats.
I remember having a similar argument with Audi - the car's head unit supported being connected to a CD changer, but you couldn't just do it yourself because it had to be enabled in the ECU (well, the body computer really). Really is just rampant profiteering.
> Unless lawmakers passed laws that made it illegal and applied it retroactively. Which happens all the time.
> You see lawmakers doing this in your face constantly. Take the Boris Johnson confidence vote for example. There weren't enough votes to oust him outright, so those that opposed him decided to push an agenda to change the rules. I don't know how far they got, because the clown resigned before any changes could take place...but it was there on the table.
Honestly, that's a piss-poor example.
Firstly, it's a convention of the Conservative's 1922 committee, not a a law.
Secondly, there was no attempt to apply anything retrospectively - such a change would have affected things going forward (i.e. letting them call another vote).
A retrospective change would be to change the rules to say something (for example, if more than 25% vote against) and then apply that to the *earlier vote and insist he stand down*.
Thirdly, even it if were a law and not simply a Tory rule, Parliament is sovereign and no Parliament can constrain a future Parliament. What that means is that they can change law at any time with no requirement that they be constrained by what they decided previously. Without that freedom, Law cannot possibly evolve with the times.
At best it's an example of how lawmakers can decide they don't like something and add new rules to prevent in in future. Problem is, that's the whole point in having lawmakers (as much as we might disagree with some of their changes).
> I can only assume that the push to regulate and fuck around with Uber was driven entirely by political folks wanting a slice of the pie. I have yet to meet anyone that is staunchly against Uber in any way.
The push against Uber was because existing businesses (cabs and taxi firms) have to operate within a legal framework that exists to ensure the safety of passengers and (to a lesser extent) the safety of others on the road.
Uber skipped these requirements and so was able to undercut the competition, carrying passengers who didn't necessarily understand that the driver's insurance wouldn't cover them if there was an accident and they suffered life changing injuries.
The fact that Uber didn't vet their drivers properly and more than a few turned around and raped their passengers didn't really help their case either.
In *some* places, the existing body of law included stuff that was there to protect vested interests, but that's a minority of the places that Uber was operating, and the issues with Uber existed everywhere.
I can't remember who said it, but there was a quote a while back along the lines of: if someone talks about disruptive innovation, you really need to first look at why the environment exists in a way that can be disrupted, sometimes there are very good reasons that regulation is in place.
> There are plenty of folks that won't use them for various reasons, but nobody that irrationally hates Uber simply for existing
I don't think there's anyone who hates Uber for simply existing. There are quite a few, though, who dislike them based on their history (which includes the stuff above).
> Unless Uber has an agreement with T5 (which seems unlikely) then this would be a shady move, no?
Not really, there's an administrative burden that goes with excluding from pricing.
Uber would need to provide the license number of all their drivers to Heathrow in order to have the excluded from billing (it's unlikely the airport's going to shoulder the admin costs of simply being notified when a Uber driver is destined for Heathrow).
> So yeah, Uber might well be shady, but that doesn't preclude everyone else around them being just as shady also.
True, but that doesn't mean we should let Uber off the hook for being shady. It just means we need to work to ensure we're holding the others to account too.
> I think we shouldn't mark a bug as 'security vulnerability' unless we have some evidence showing it can (or at least, may) be exploited," he wrote, adding that nonetheless 3.0.5 should be released as soon as possible because it's very severe.
> "I'm not sure I understand how it's not a security vulnerability," responded Gaynor. "It's a heap buffer overflow that's triggerable by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake)."
Personally, I think they're both right.
We need to be careful about labelling things as vulnerabilities if there isn't any evidence that they might be exploitable. Otherwise, much like the vim example, you get a wash of "security vulnerabilities" which'll lead to operators, users and admins becoming complacent about installing patches (oh they label everything a vulnerability nowadays....), negatively impacting the chances of getting fixes for exploitable issues installed quickly.
But, that doesn't mean that *this* instance shouldn't be called a vulnerability - it's got all the makings of one, it's remotely triggerable using something the other end has control over, all that's really missing is that no-one's (yet) figured out how to misuse it. Whilst they might never do (a buffer overflow is never good, but it's also not always exploitable), the fact that it can be triggered remotely creates a window of opportunity for anyone that can figure it out. So the second quote is right too.
I'm not sure I agree with the assessment that this is worse than Heartbleed, the "badness" of a vulnerability is about more than what you can do with it (after all, we don't describe privilege escalation bugs as "worse than heartbleed"): the real-world applicability has to be considered too.
This vulnerability applies to a (very) limited subset of installs, which need to be using specific hardware. Heartbleed affected (more or less) anyone running almost any version of OpenSSL that was available - you could do less with it (at least directly), but you could use it against the majority of services on the web. In my book, that's much worse. This still needs fixing though.
The only way to ensure that the data doesn't get used is *not to collect it in the first place*.
It doesn't matter, one bit, what promises are made about what they will and won't do with data they hold, there are so many unplanned ways it could get out, including the service getting compromised and data leaked onto the net, or certain States getting even more authoritarian, with doors kicked in and servers seized.
You only have to look at the laws being put in place in places like Mississippi to realise that you're not talking about rational people here. Fuck, at one point a Texas "pro-lifer" politician wanted the death penalty for anyone who had an abortion. We're talking about crazy people who've been given a taste of power - it's best to assume that the worst is yet to come and to protect users by not holding any data unnecessarily.
> You know (apparently first hand) that the monthly cost of building a resilient app runs at least 6 figures a year.
Again, we're talking about different things here.
You're talking about end-to-end resiliency in an application context, I'm talking about a feature that makes it possible to cope with a failure in an edge provider (Cloudflare in this case).
You're talking in the context of an application server, whilst CDN's primary domain is serving (and caching) static content (the big money is in serving game artefacts and video). We're talking about completely seperate problem domains with very different solutions.
It's not nearly as expensive as you make out. In fact, it can even be achieved for as little as £60/year (though that price point doesn't come without issues, the risk is still lower than with your authoratives tucked away inside CF).
Fuck, you can do it nearly free if you don't want it automated:
- Have DNS across providers
- CDN1 goes down, update CNAME to point to CDN2
Not that I'd recommend it, but your recovery rate will still be faster than without the ability to switch away.
Something more production ready like Cedexis or Constellix doesn't break the bank either.
The days of CDN being an expensive bespoke thing are long gone, it's a commodity nowadays. Multi-CDN support isn't much different in that respect
I've focused on resiliency because that's what the article is about, but there's a bunch of other knock on effects too. In the early stage of the relationship It knackers a customer's ability to do A/B testing.
Big customers also tend to use different CDNs in different parts of the world - If Cloudflare's coverage is pants in parts of Asia, you might route those users via AliCDN or similar etc. The lack of CNAME support hampers this.
The key thing with both examples is that you generally want it to be transparent to the user, which generally means CNAMEs (I've seen DNAMEs get used too... the horror)
> Against that level of spending, you're going to weigh $2500 priced as an addon?
I think the thing you're missing is that that $2500 is an otherwise unnecessary charge unless you also want support from CF.
It also comes on top of whatever you're paying to implement failover. If you're using something simple (like DNSMadeEasy's fairly limited auto failover) then that 2500 increases your costs many times over.
If Cloudflare were head and shoulders above the competition you might ignore it, but in many locations, they're not.
> But any evaluation of a solution has to be based on total cost
Evaluation of a solution is based on *value* not cost.
CDN customers tend to have a spectrum of criteria. Some will pay the earth for the provider with the lowest latency (in whatever market they care about), some want to spend as little as possible.
Most, obviously, fall somewhere in the middle.
If you're charging extra for something basic that your competitors offer, you need to be able to justify it, either through sheer speed (attracting the left of the spectrum) or by being able to explain that its omission makes lower tiers cheaper (a hard sell with this particular issue).
That's not something Cloudflare have achieved IMO.
> You attacked their business model over this
I think you've overlooked the context I posted under.
My original comment quoted a bit from the article that said it was unacceptable that a single provider could take so much of the net down.
The point in my comment wasn't to attack CF's business model, but to point out that that SPOF was there not because of technical reasons, but because of a business decision by CF.
The guy quoted in the article is a little breathless, but he's right, this should and could have been avoidable.
> How many of the stone-throwers here have ever worked in, let alone managed, an operation of Cloudflare's scale?
As you've specifically called out my comment (whilst missing the point), I'll answer.
In fact, I've also worked with customers who considered themselves too big to deliver via Cloudflare, and as well as building and managing global CDNs, I've built and integrated against a number of multi-CDN solutions, working with customers that you've definitely heard of (and on a balance of probability will likely interact with sometime today).
I don't really do calls to authority, but if you're concerned I'm griping with no view into the industry, I'm not.
> First, if $200/mo is enough to matter, then you are not spending enough on resilience for me to care what your opinion is.
You've completely missed the point.
It's not just the cost, it's the fact that their solution is architecturally flawed for no reason other than commercial gain. Cloudflare is the only provider who charges extra to be able to CNAME in.
The true market leader, where real money is spent (Akamai) offers DNS services but does not mandate them: to do so would mean forcing your customers onto a possible SPOF.
That $200/mo by the way, may not give you much else extra that you care about (xepending on your requirements), you're just paying a premium for something that's a basic feature on basically every other CDN.
It'd be much better to be able to spend that $200 on Cedexis or similar so that you can move traffic about.
> Resilience happens at every level of the stack, and it is a sick joke to suggest that it can be achieved on a shoestring budget.
There's a cost, sure, but that doesn't justify Cloudflare's commercial choice.
Perfect resilience costs a lot, but that's not what we're talking about here, we're talking about building multi-CDN: resilience against single provider failures.
That absolutely can be achieved on a shoestring budget (though I wouldn't recommend it).
You're letting perfect be the enemy of good, and even a few years within that segment of the industry, seeing the things that big companies actually use/do would show you how wrong you are.
> they are showing FAR more transparency than we generally see.
Cloudflare generally do, their post mortems are open and honest, something which they should rightly be praised for.
> This morning was a wake-up call for the price we pay for over-reliance on big cloud providers. It is completely unsustainable for an outage with one provider being able to bring vast swathes of the internet offline.
Multi-CDN is relatively easy to set up nowadays, and isn't even that expensive.
Unfortunately, if you want to use Cloudflare then you need to have your DNS with them - at least, unless you're willing to pay $200/month for their business tier in order to unlock support for CNAMEing to them rather than giving them control of your zone.
There's not a *lot* of point in setting up multi-CDN if your authoritatives are tied to one of the providers that you're trying to mitigate against.
It's a business choice by Cloudflare, but is part of the reason that outages there are so severe. If something happens to Cloudfront, Akamai, Fastly etc then there's the option to flip traffic away from them (it can even be done automatically) and serve via a different CDN until things settle down.
It's a core part of why I neither use or recommend Cloudflare: they might be huge, but they're still a single basket and mistakes happen. Not having an option to move traffic away from longer outages isn't really acceptable.
> poorly designed
Saw something recently about their gull wing doors.
The doors (obviously) rely on the electrical system being operational, which isn't a given after an accident.
Obviously, there's a need for a manual override so that you can still get out in an emergency.
It turns out, Tesla hasn't seen fit to normalise this across their range, relying on passengers having read the manual to know where to find it:
- Some models: hidden behind a grill in the bottom of the door
- Other models: trim in front of the window controls pulls up
- Model Y: No manual release in back doors, climb into front and use manual release there
As an owner, you might then feel you want to practice periodically so that you can be sure you're going to be able to do it while in distress. Except that's recommended against because apparently usage of the manual override can damage the doors.
So, you've got a car where in an accident you're expected, whilst potentially panicked, to be able to identify where the manual release is expected to be and to be able to operate something you've never operated before. If you're transporting kids in the back, you also need to have made sure they know they need to climb into the front to escape (because you might be unconscious or dead and unable to tell them when it's needed).
People can argue themselves blue in either direction about whether the name "autopilot" sets unreasonable expecations or not, but there's no avoiding the fact that Tesla haven't even managed to get the basics of safety right.
From the article
> Our main argument is basically compliance with the law implies costs for a developer that hadn't adhered to [GDPR and related data protection] principles before the regulation kicked in,"
So GDPR creates cost for those with poor data handling practices, and some of those developers would rather give up than comply?
Sounds like a win to me
There's much, much, much more to Github than just repo hosting.
The interface provides project management, CI etc etc etc.
But, the biggest reason for using Github tends to be discoverability - unless you're already a big project, you'll likely get much more use and many more contributors by being on Github. Especially for small drive-by fixes (almost no-one's going to create an account on your server to fix a small UI bug, but they might chuck a quick pull request, or at least an issue report in on Github).
Although it's not generally what you think of as social media, it has many of the same effects - you derive some benefit from being where the users are.
I host my own git repos for various things, but it really is an incomplete alternative for many projects.
> But now seeing it is Microsoft, they'll use their own app.
> If it was based on standard TOTP, then there's no data to mine.
Last I checked, Microsoft Authenticator *is* TOTP based, so you can easily use Authy, Google Authenticator or a python script instead.
Github don't just support TOTP 2FA anyway - I use a U2F key as a second factor, with TOTP set up as a fallback
Microsoft would have to scrap an awful lot of the existing 2FA implementation to turn it into a data mining operation.
I'm all for cynicism, especially about data collection, but this isn't one of those times
> These patches are advertised why before they are available due to the end user, so teh bad guys are handed a window of opportunity on a plate.
Sorry, but for the majority of issues this is wrong.
Issues get reported on the (closed) OSSEC list where they're handled under embargo until the participating distros are ready.
By the time they get announced, the change is already in the repos of quite a large number of distros.
It's true that sometimes things come out first - researcher doesnt want an embargo, someone makes a commit public by aciddent etc etc, but for the vast majority of issues your comment is just uninformed misinformation.
TBH, the bit that scares me isn't so much the bugs and security holes so much as the fact that the entire model is predicated around a pretense that they don't happen.
Bugs are going to bug, but with smart contracts there is no way for a human to intervene and set things straight.
So some unknown developer knocks out a contract over a bottle of wine, sets it live before passing out, and it's effects on anyone who interacts with it are immutable (outside of a blockchain fork).
Considering the sums involved with crypto, it's beyond irresponsible, but often gets mis-stated as being a feature
It's a test page I created when I made FKAMP.
You *should* end up on good.html rather than bad.html (the AMP version), at least if my reading of how De-AMP handles that scenario is correct
> More people die of CANCER, HEART ATTACKS, CAR ACCIDENTS and DRUG OVERDOSES per capita in the USA
None of which are communicated onwards to other people (though I suppose technically you could argue you communicate a car accident onto the person you hit)
> If I Remember Correctly.
The USA lost 301.27 people per 100K to COVID (that's mortality alone, it doesn't include those who were debiliated by it): https://coronavirus.jhu.edu/data/mortality
The cancer mortality rate in the US is dropping, but at it's peak it was 215 per 100,000 (https://www.healthline.com/health-news/cancer-status-report-overall-death-rate-continues-to-drop) - less than covid
Heart disease is normally one of the leading causes of death in the US (https://www.cdc.gov/heartdisease/facts.htm), apparently 1 in every 4 deaths is heart disease. But heart attacks are a smaller percentage of that - 805,000 people every year (actually I'm being generous, that's the number of people who have a heart attack, not those who die). With a US population of 329.5m that gives us 8.05 per 100K people.
Drug overdose is apparently 21.6 per 100,000 (https://www.cdc.gov/drugoverdose/deaths/index.html)
This has turned into a blob of text though, so lets list these in descending order
- COVID: 301.27 / 100K pop
- Cancer: 215 / 100K pop
- Drug overdose: 21.6 / 100K pop
- Heart Attack: 8.05 / 100K pop
So, no, Bombastic Bob you do not recall correctly. In fact, you're so far wrong as to be talking out of your arse.
That sounds like an argument for the lockdown rather than against it.
What you're effectively saying is that they're lying about the death rate (and potentially the infection rate too) which is much higher.
So, the lockdown has an increased chance of reducing harm, not a diminished one - at least before we factor in the cack-handed approach to things like supplying food.
Read my comment again, and realise that what you're commenting on is the *result* of the lockdown not the cause of it.
There's also a real danger in focusing only on deaths. How many of those 371,997 cases are going to suffer serious long-term effects?
Sorry, but you're wrong on two out of two counts.
> idiotic decisions like locking down 25 million people to prevent 3 deaths
That's not how statistics work
It's not to prevent 3 deaths, it's to prevent many more than that.
The lockdown, as badly implemented as it might be, probably has been successful at reducing covid spread and deaths. You can't really judge how many deaths it might have prevented based on the numbers achieved by the measures.
What you should be arguing is that near death by starvation really isn't much better. They've effectively recreated a plague village, with the citizens being starved for the "benefit" of other areas.
> If the world ends up misinformed or polarized, that's the world's fault, not Elon's.
Worse, he'll claim that the best way to address fake/false statements is more speech telling the truth.
Which is true, in principle, but tends to fail when you've got someone setting their millions of followers on anyone who points out that they're spreading bullshit and/or putting lives at risk for their own commercial gain.
> In the US, all-caps acronyms are a common way for lawmakers to embed some aptly pandering phrase within legislative shorthand. For example, consider the DISCLOSE (Democracy Is Strengthened by Casting Light On Spending in Elections) Act of 2015. Europol, however, appears to have resorted to capital letters merely for emphasis.
It's the same with military ops.
The left-pondians tend to make some kind of political point when naming, whereas we use a computer to generate a random name so we've sonething non-political but specific to call it.
Capitalisation of the name in written comms is the accepted style (although not consistently mandatory)
Take the war in Afghanistan for example:
US: Operation Enduring Freedom
UK: OP HERRICK
Same sort of thing with Iraq
US: Operation Iraqi Freedom
UK: OP TELIC
TBH, I always found the US way weird - there's no real brevity benefit in "Operation Enduring Freedom", you may as well just mention the specific theatre. It also leaves open the chance of a name change if the name becomes inappropriate for some reason.
It's a bit like naming vulnerabilities, it's useful to have a name to refer to things by, but it doesn't need to mean anything (and it doesn't *have* to be a bacronymn)
> This is why moving your "stuff" to the cloud is probably not the best option for a lot of people.
Statistically, there are likely some affected users who were all but forced into the cloud.
Atlassian axed their on-prem versions (unless you want to pay for a datacentre license) about a year back.
> It can sound harsh, but you've simply got to do it - no matter how much you may think you can trust that person.
I always position it as it protecting that person too.
If someone does something on the system shortly after you've been dismissed, you don't really want there to be any question about it might have been you (if nothing else, you want to be sure you won't be scapegoated).
It protects both sides, which is far less harsh (though still won't feel that way when they come out of the office to find themselves locked out).
Well, to be fair, you're not going to state right wing opinions in court having said "I swear to tell the truth, the whole truth and nothing but the truth".
Seriously though, got a link to back that up? There's a world of difference between "demonstrated in court" and "found by a court".
Adding MFA does improve security.
Putting all your eggs in one basket, though, not so much.
The problem with Okta etc is that they're also an authentication provider - they handle your username/password as well as your 2FA. Which makes them both a juicy target and a single point of failure.
But, the counter argument is: do you leave authentication to a specialist, who has the expertise on hand to detect, prevent and deal with stuff like this, or do you keep it in house where you don't have the resources?
Using a 3rd party supplier also helps to potentially avoid a facebook like outage where your own engineers can't get in to fix things because your inhouse auth is down.
But, Okta's failure to tell customers about a suspected compromise really does undermine both arguments, if you can't trust your auth provider....
> And how many of these vocal complainers are actually paying Github for service?
Surely, as they're not paying then, GitHub should *not* give them this new feature and only foist it onto people who've paid for the privilege?
I've only take a quick scan over mine, and there's nothing in there I could ever imagine being worth inclusion in a personalised feed.
Compromises happen, even to authentication providers.
What doesn't instill trust though, has been Oktas communication about the issue.
They've gone from "no, it's just something that happened months ago that we never mentioned" to "yeah, it was months ago, and it turns out they accessed some customer data, we're making contact"
Forensic investigations take time, it's not Okta's fault they only got the report back recently, but they should have been proactively contacting customers *in january*.
They're a gateway to a myriad of other systems, there's absolutely no excuse for having left those systems at risk despite knowing that a "limited" compromise of their own systems had occurred.
All they needed to say was
"Dear customer, we've detected a possible security incident with a third party supplier, we're investigating, but please consider whether you wish to reset access credentials"
Instead they kept quiet and let their customers shoulder the risk.
Not exactly a ringing endorsement for a provider that's supposed to be part of your first line of defence
It's as simple as that, the app orders new ink for you when the ink runs low. It's pushed hard and is an easy sell because they aren't upfront about their habit of locking out printers *and* the cost is lower than just buying cartridges (from HP/Epson direct at least)
I've had to spend a lot of time explaining why it's a bad idea.
> While it would be nice to feel good about supplying shelter to the refugees, that is probably best supplied by countries closer to them
I disagree, but even if I didn't - your point would only really be valid if we as a nation explicitly said that.
- putting a little paper notice up in Calais
- lying about whether there's an office in Calais
- saying that we're taking refugees but they have to pass all the visa stuff (and pay the fees!) first.
- Complaining that the Irish have taken refugees in the way we should be, and that it might pose a security risk
So, even if your suggestion that other countries are better placed to help them were correct, the way that the Government have handled it has been woefully inadequate.
Taking in refugees doesn't really hamper our ability to supply boomsticks either, so it's not like one actually distracts from the other anyway.
> It doesn't do much to directly make a dent in crime since criminals tend to use unregistered illegal guns.
It does make for a slightly easier prosecution when you catch them though. By definition, there needs to be a registration system for anything to be considered unregistered.
> Licensed gun owners are typically very responsible people, have been screened, and secure guns against theft
And again, that's because there's a registration system in place. Without a registration system, there's no *verifiable* screening system in place. Criminals would generally still use stolen firearms, but they'd have a much wider base of people to nick firearms from.
> If, however, these 'giants' are proposing a closed garden standard, they'd also need to run the access networks and CDN infrastructure, globally.
I can understand you never having heard of Tencent, But Alibaba?
Hint: They've got global CDNs already. Bytedance has been building one too.
If they *don't* share, but are able to show dramatic improvement, then they potentially have a unique selling point to draw publishers to their CDN(s). It never works _quite_ that smoothly in practice, of course.
> I bet they haven't addressed legacy users either, which would be illegal in some territories.
I'll bet you're wrong :)
In my experience, the Chinese video companies is never a lack of support for legacy technologies, if anything it's moving forward onto newer/better standards that's the issue. So the challenge they really face is simplifying that enough to drive adoption - although between them, they own enough of the market that they can focus on their own customer base.
Biting the hand that feeds IT © 1998–2022