Agreed. However, I think the author fears that, just like smartphones, some will become socially pressured into getting one and it will cause them harm. So they're issuing a kind of public warning.
> Not to mention that talking about 'the major players in desktop Linux' is completely against what the OS ethos was supposed to be about; he said the quiet part out loud, and people strike back; it is only fair.
He also said[1]:
> We don't have the time
And then he said[2]:
> If you want to change that, better volunteer yourself :)
Rather, I think he's saying the loud part out loud. OSS can have an opinion, and you're free to modify it to suit your own opinion.
Disingenuous. If someone turns up willing to volunteer, there will be some other excuse. They do not want volunteer effort to do something they don't want done.
Even fully baked patches will turn out to require "incompatible architectural changes".
In social justice (a key component of how open source projects operate today) we have this concept of "doing the work", which is as much about humbling and decentering yourself and recognizing that there is a community of others involved whom your efforts must support, as it is about putting in the actual effort.
Eric S. Raymond likes to contribute to open source projects in the form of fully realized, thoroughly architected megapatches that totally upend all the assumptions about how a system/subsystem works and behaves, along with a long lecture about why his patch should be accepted which boils down to "I'm ESR, I know how this bit should be designed much better than you, so there". That is the exact opposite of doing the work. Doing the work involves empathy and respect for the needs and experiences of others.
If you want Asahi Linux to support Xorg, you have three choices:
* Accept things as is.
* Fork the project.
* "Do the work". Convince the Asahi maintainers, in terms they are likely to appreciate, why Xorg inclusion is a good idea and who will be assuming the maintenance burden with little to no effort on their part. Then try to merge your patches.
You get sued - so what? The most they can risk is the ability to have a UK based payment processor bail on them - they can still have customers in the UK, but they'd have to pay via a VPN.
I think you misunderstand, I was talking about a UK based company. If the Companies House decides to rescind your registration -- you are no longer a company. That is what you risk.
You don't actually need a real address in the UK to open a company there, an address at one of those virtual offices is enough, so you could conceivably avoid the criminal case (if you live in a country that won't extradite you!). What you couldn't avoid is the UK telling you that you are no longer allowed to be a UK registered company, which is obviously within their rights to do.
The UK can only ask Germany to 'do something about it'. Courts apply to entities over which they have jurisdiction. UK isn't even in the EU anymore, they have no power over a German mail company.
The UK has no jurisdiction in Germany - they are separate sovereign states. It would be up to the UK to prevent them serving UK customers, because - as long as their own government dont interfere - they could just ignore any demands. This is just as true for the GDPR.
Once logged in, go to account security. There is no facility to add 2 factor auth. (as of Feb 2023)
Compromising someone's registrar account and hijacking their domain(s) can have serious commercial consequences. I'd love to hear 123-reg's excuse for still not implementing 2FA.
Is there a way to disuade users from blindly trusting responses? Such as unavoidable caveats, make no attempt to provide depth and instead strongly recommend reliable research?
And as a logical aside: if AI can't be trusted, we shouldn't trust AI's recommendations for reliable sources either.
> And as a logical aside: if AI can't be trusted, we shouldn't trust AI's recommendations for reliable sources either.
Don't think that's automatically true though: an AI can be consistently excellent at retrieving reliable sources and still get a lot wrong on its summaries. Also humans have their own opinions on sources even when they're not familiar with the detail, and finding out if the AI reads Nature or 4chan is part of the debugging process...
Sure. Really, I was thinking of the scenario where someone explictly asks for a reliable source i.e. "Thanks for summary about X. To whom should I turn for more accurate/detailed information?"
Oh yeah, it's spectacularly bad at some of that sort of thing. Ask for a list of academic papers and it'll make half of them up and give others new authors...
It's the same thickness so who knows if the battery has more capacity. I would think it's more likely that going from A13 7nm to A15 5nm chip nets ~20% battery
So it turns out "the phone has a physically larger battery — a fact about the new iPhone SE that the company confirmed on background in a group briefing with reporters." When teardowns are published we can see exact mAh.
Interesting to see this and the gp--especially how others are thinking/communicating about them. I have been picking at something that uses css in a similar way, but I've found it difficult to put what it is into words.
Sorry to hear that you had a bad experience. That's definitely not the culture that I'm experiencing every day or that we hold ourselves to. Our goal is to deliver a ton of value to customers. If we are not delivering value then it would not be in line with how we operate to want to charge you for that.
Out of curiosity, did you try contacting AWS support? Almost all customers I speak to love our support and the fact they can speak to an actual human. Of course I can't speak to the actual case as I'm just providing my personal opinion here, but I would not be surprised if support could fix this for you quickly and zero out any small balances that you accrued because you weren't able to access/use your account.
With all due respect, it has nothing to do with culture and more to do with business processes having rough edges. At AWS' scale, any rough edge is more than a rare edge case, since rarity flies out the window.
Spending more to provide better customer service (explicitly or implicitly through bugfixes) is not generally how this type of need is. Folks shouldn't need to post their grievances to a very public site to be heard, and that it needs to happen to get traction on an issue should be taken as a clear gap in customer service provision.
> I've had to ask my credit card company to block AWS charging an account that I can't remember the login to.
We don't know whether OP has reached out to AWS support, but one can assume so since AWS is charging an account the user cannot log in to.
Further, it sounds like the user has found their own resolution, so the user isn't asking for _help_ on HN, more that they are registering poor experience in agreement with others. So, it is a rough UX edge.
> Folks shouldn't need to post their grievances to a very public site to be heard, and that it needs to happen to get traction on an issue should be taken as a clear gap in customer service provision.
Yet by your very own comment you say that we don't know if he actually tried to contact support so there is no "clear gap in customer service provision".
The fact is, anyone who actually interacted with an AWS rep would tell you that they would delete the bucket and not charge you for it.
From my own experience, no you can't. All links to cknta t support require you to have an active AWS account. That defeats the purpose. YMMV as in maybe it's different today but that was my experience. And I was just trying to them to stop sending me spam after I had closed out my account.
It's weird to see hackers here posting this as AWS is literally the only web scale company I can actually talk to a person at to resolve rough edges.
This is both on retail side and AWS side.
My only request - do some more automated discovery and remediation tooling for VPC-classic accounts! It's annoying to figure out what needs to be handled there - give me a dashboard for this.
I'd really be curious how much money AWS makes on zero-usage accounts where someone spun up something and then forgot how to log in or delete it.
I've been paying $10/month for over a year on an EC2 (I think?) instance I spun up, and I still haven't had the time to go in and find it and delete it. I've tried several times (and even disputed the credit card charge one month).
I'll probably just end up cancelling this credit card. That would be a lot easier than figuring out how to stop AWS from charging me.
> I'll probably just end up cancelling this credit card. That would be a lot easier than figuring out how to stop AWS from charging me.
Nooooo no no no that is not true. If you cancel, this debt will follow you on your credit history and via collectors. Canceling a CC does not waive you of responsibility.
Just contact AWS support. Tell them your story. They’ll get your account closed and they’ll probably forgive whatever outstanding bill you have.
Please don’t just run away from the bill, you’re just setting yourself up for pain later.
I've actually contacted them via email multiple times, and they never respond.
At this point, they're legally committing fraud. I don't see how closing a credit card that has regular fraudulent transactions is wrong, or likely to cause problems later on.
> I've actually contacted them via email multiple times, and they never respond.
> They are absolutely not commiting fraud - that is a total lie.
Lie isn't the word you're looking for when you disagree with someone.
If they never respond they aren't engaging with the OP to figure out what this person want's. If the OP even contested the charges AWS has been warned that someone isn't happy with the contract. Both by personal email and by the credit card company.
> They are absolutely not commiting fraud - that is a total lie.
If I write an email to them asking them to cancel an account, doesn't that constitute legal termination of my authorization to continue service or charge me?
Unless the service agreement I signed specifies a specific way to cancel an account - in that case my agreement to it constitutes authorization unless I jump through their hoops. Argh.
Remember, canceling your account means everything (EVERYTHING) is deleted. They are far far more concerned that someone will randomly email them pretending to be the CTO of some startup or you, and they will blow away 3 years of someone's work.
Canceling your account even cancels glacier, WORM records, object and compliance lock data etc.
Everything I've seen says that AWS rightfully biases towards retention unless the delete request is very clear - and email will never rise to that level (nor should it!).
So you have to login and close your account yourself.
How you get from a very reasonable business practice here (and they are frankly one of the easiest of the major players to actually talk to) to fraud... is a stretch.
Edit: For those not familiar with AWS account closure here are the steps:
I'd login and go look at your most recent bill, this should bring up the bill from September 2021, for you [1].
That should give you a breakdown of where the charges are coming from, specifically which region an EC2 instance might be running in. Once you can figure out which region it's in, you can go to the EC2 dashboard for that region [2] and start terminating instances.
Having said this, AWS should seriously have a way to say "close this account and delete/stop everything associated with it." Having to spelunk through bills and the AWS console to figure out what you're getting charged for is a joke.
How hard is it to stop an EC2 instance? It's literally 3 or 4 clicks from when you login. As for forgetting how to login, if I give some company my credit card info, I damn well make sure I know how to login when I need to.
Why can't we bill them for wasted time and stolen money, send those bills to collection and ruin their credit? Something seems unfair about the power dynamic.
Well, you can document your attempts to close the account and report it to the police. It's just a lot of work and you will only gain a document you can use to press your credit card issuer into rejecting the payments.
Also, if they do send your debit to collectors, you can go to a court and ask for the debit to be dropped and for them to pay damages. That is a lot more work, but if they are clearly on the wrong will get you something.
Theoretically. I don't know in what cases Amazon might do either of these things. If you're not in the US, that's certainly another layer of barrier.
But yes, in the US anyway, whether you legally owe someone money or not and they can legally collect on it is not controlled by whether you've cancelled a credit card.
I'm completely amazed that such a large group of developers have decided to put their personal credit card on Amazon. Foolish choices lead to bad outcomes.
When does billing by the hour for storage/everything start to seem appealing?
I wanted to use ECS/Fargate earlier this year and the deploy kept failing. It was an issue on my end, but the infuriating thing was that Cloudwatch didn't have any logs 80% of the time. Like, at random: I could click the redeploy button 5 times and 4 of those times wouldn't have logs while one would. Of course, they charged me per deploy. I ended up running up a bill of $100 before I said screw it and used DigitalOcean instead (where I had logs consistently and was able to debug my container deploy within about 10 minutes and only a few cents of a bill).
I had a similar issue when moving our stack to ECS Fargate. logs wouldn’t tell us anything other than ‘application was terminated’ within seconds of it booting. The most helpful thing was looking at the reason given for the container shutting down(which still was a difficult riddle for a Fargate noob).
In our case, it was a message saying something like ‘container timed out’ originally making us think it was a network issue. We ended up tracing it back to our app sometimes taking 21-30 seconds to fully boot, instead of the 20 second limit Fargate had for health checks. So even though the container did end up booting, Fargate was already waiting for it to start so it could kill it.
Yeah, my issue was something similar. When I moved it to DigitalOcean, I was getting logs consistently (from my application) and I traced it to something that was misconfigured on my end, which was causing health checks to fail. It took a total of about 10 minutes to track and fix on DO, while I had already spent 2 days (and the $100) trying to figure it out on AWS.
I mean, the issue was my fault, but AWS made it incredibly painful to figure out and fix and was not helpful at all. I decided that day that I will never use AWS again, unless I have someone with a lot of AWS experience on the team (and even then, only if I have a good reason to use AWS, in my case there is a reason why AWS would perhaps be desirable in the future but not enough to go through the pain again myself).
There's nothing particular about Amazon here, any company or person you owe money to in the US (can't speak for other countries) can take you to court or turn your debt over to a collection agency.
I haven't heard of Amazon specifically ever doing either of these things.
Or am I missing what you're saying is particular to Amazon and relevant here?
And you use the Fair Credit Reporting Act to force them to validate the debt or cease collection activity. For small amounts they will not go through legal hoops.
Often yes. And perhaps more importantly: you don't need a SSN to send a debt to collections or report it to a credit bureau (though of course it helps).
Legally shmegally. Just download one of the many troves of hacked databases. I'm sure you'll find the data you need somewhere. Or hire a 3rd party that does stuff on your behalf. Now you have plausible deniability in that you're the one not doing it.
And WebSockets and WebRTC and form submissions and so on. It'd be a whole policy for many things like gp suggests not just blocking one function.
Of course that being said the policy would basically have to be "disable network" at a trigger point not just uploads as you can just as easily leak large amounts of data via triggering GETs by making img placeholders come into view or other equally tricky things that can't be distinguished from "app is just still loading".
Even just basic hyperlinking would have to be heavily restricted.
For example...
1. Cross origin hyperlinks would have to be completely disabled
2. Same-origin URLs would need all url information (query params, path, etc) to remain completely client-side. The only thing transmitted to the server would be the base domain.
Post restriction there is no such thing as allowing network requests (same origin or cross origin) without opening a side channel which can work around said restriction (e.g. timing). However pre restricted mode there is no reason to restrict anything be it same origin or cross origin.
Pre-restriction would have to disallow running javascript in that case. Otherwise an app could save data to localstorage, refresh the page programmatically (or wait for the user), and then transmit.
Or rather have the browser treat the no-network session period with private window logic where the session is deleted if the no-network browsing session ends or dies (e.g. incognito puts a virtual session data container in RAM). That would even allow the app data (prior to triggering the mode) to stay cached without risking side channels with future resource loads.
The whole premise was to return to the pre-web 2.0 days but have the option for a user to enable modern web app capabilities. Which your idea would be a step towards.
