I had a very similar single experience with Om: I was introduced completely randomly while he was at True Ventures; he couldn't have been nicer, more curious, or more genuine despite me almost certainly reading like a total waste of time.
It's both heartwarming, and bitterly sad, to see so many other posters confirm he was one of the good ones.
Layoff announcements are this kinda tricky class of corporate comms where you need to speak to at least 3 different constituents, with 3 different messages, which are often in conflict.
It's something like:
(A) To the public (e.g. prospects, customers, investors): "This is a good thing and we're going to be an even better bet!"
(B) To the remaining team: "This is tough and I feel your pain and will do better."
(C) To the laid off: "It's not you, it's me, thank you and good luck."
It's hard if not impossible to handle all three of these authentically, concisely, and in the same message. Which is why you can almost immediately find something not to like..
There's really only a conflict between A and the rest, and that's because A is a lie. It's not a good thing, if it were they wouldn't have to say B and C.
They can try to do better and be hopeful, but they also fucked up big time. It's not like the public actually believes the lie, so stop telling it.
I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method.
(pi.sh also documents other install methods, like `npm`, on their homepage)
If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass
> I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world.
It's plain horrible. You could have, for example, a compromised server serving malware but only one out of every 100 download. The only signature you rely on is TLS.
Proper package distribution are using proper signatures schemes, are decentralized, even for some offer reproducible builds (meaning you can rebuild the whole package yourself and verify your build matches), etc.
Hashpipe is an attempt at reproducing some of those guarantees. Not unlike container pining using hashes. It at least fixes the "Jack and John installed this already and I know I'm getting the same version as they did".
Proper software distribution is signed, reproducible and ideally also uses some proof-of-existence for the hashes.
My bet is this: in the face of the countless supply chain attacks, we'll see more and more people getting very serious about security, including the security of software distribution. And curl bash'ing won't be part of it.
Package managers: ecosystem is fragmented, requiring a long list of distro- and package-manager-specific instructions. Many scripts already install through package managers, they simply make the user’s life easier.
Flatpaks: These are clearly designed for desktop applications, with CLIs treated as an afterthought. They may be the best long-term hope, but today they are definitely not as convenient or widely available as a simple script.
If you care about adoption, `curl | sh` is the only real option today, which is why virtually all project show it as the first option.
The "like an adult" is what has and will continue to hold back linux on the desktop. Always gatekeeping less technical users instead of acknowledging adoption and ease of use are critical.
A lot of those scripts are wrappers around package managers. Creating them is extra work for distributors, but they still do it because package-manager installs are not truly one-liners and offer far less control over the installation experience.
Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor.
And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved.
For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people.
In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there.
A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help?
It is much simpler, much safer, and easier to maintain a package than an install.sh, eapecially for a big project.
Configuration can be handled by a script, yes. Here's a crazy idea: Your package can include scripts for configuring the software. It's almost as if most packages do. The scripts/utilities could even restart a systemd service for you.
Unless you're talking about configuring your build, in which case we're dealing with an experienced developer who will have no trouble just cloning the repo and building from source.
My biggest issue is: if we're dealing with someone who can't use a package manager, we're dealing with someone who doesn't have the capacity to judge how safe a script downloaded off the internet is. This does not drive linux adoption, it drives botnet adoption.
It's crazy to me that even after seeing so many major software distributors choose `curl | sh` as their entry point, people like you will still argue to the ends of the earth that there’s no problem with the package manager ecosystem.
I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.
Bad faith, or perhaps just ignorance. It reminds me of purist junior engineers - and I have been one - refusing to understand or tradeoff in the world beyond their own.
Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.
Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this.
I would appreciate it if you would respond to me directly rather than suggest vaguely that I'm inexperienced and don't understand the realities of software distribution.
I would also appreciate it if you actually talk about something concrete rather than simply claiming to be right. You shouldn't pipe stuff from the internet into your shell.
Are you claiming that's about some highfallutin "technical purity"? Is it technical purity to check inside the bag when you buy a pig in a poke? No, that's common sense. It's common sense to have some degree of knowledge about what programs you execute on your computer. As root, at that.
Sure: I think you're essentially missing a whole set of concerns - ones that are not purely technical - behind why this method is popular; and so your arguments wouldn't convince someone actually responsible for one of these scripts to change or cease the practice.
Nobody would argue that it's categorically safe/good/smart to blindly pipe a script into your shell; and for the record, I agree. I would also readily agree that habituating users to doing this probably creates new, more general risks especially among how less-technical users interact with their CLI.
However, the realities of the "real world" make it popular for a reason, in light of those negatives; tons of scaled projects continue to offer a 1-liner. So we have to ask, why? They'd probably say that's because it (a) improves project adoption, and (b) reduces "install broken" tickets.
You have to address the non-technical merits and goals to get behavior to change here, and sadly, I don't think anyone has done that.
But who cares about me? I'm not currently maintaining one of these (though I did once). My suggestion to bring your argument to an active project was genuine: try it! I'd be delighted to see you bring about the change you want.
[PS: The commenter I replied to originally used the term "bad faith", which they've since edited]
The fact that people do something doesn't make it good.
I am arguing in good faith about the merits of the approaches. I am engaging with the points of argument being brought up from the opposing side of the argument (see above). I am not veering off on side-tracks, unlike you, for example.
There' a simple good faith argument (that I have been making) which you can try responding to: Running arbitrary code from the internet without checking is bad. There is some effort needed to package software, but that is not that much effort in the grand scheme.
Most official repositories have policies that are incompatible with the needs of software vendors (release timing, supported versions, bundled dependencies, etc...).
IMO a lot of the blame falls onto the package manager ecosystem refusing to take into account very valid needs and claiming they aren't real / desirable.
i dunno, nothing about most computing is particularly easy to use or intuitive.
what has worked over time is having computers of various types in schools, where teachers teach students and let them play with it.
nobody teaches about the command line, so nobody knows what to do with it. its also inscrutible without a useable help view, unless you already know how to use the terminal
Windows, macOS, iOS, and Android are definitely much easier to use and more intuitive than Linux today. That’s because their developers are incentivized to put themselves in the shoes of less-skilled users and figure out how to build a good experience for them.
I’m all for higher Linux adoption on desktop, but there’s still a lot of resistance to making less-skilled users the primary target instead of power users.
Teaching can help, but if it takes 50 hours to learn the basics of Linux versus 5 hours for Windows, it’s a losing battle.
The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods.
Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example.
When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have.
There are many ways of implementing a curl | sh installer, some of them robust, some of them not.
However they all look the same to the end user.
That's a feature and also a potential source of problems since users cannot tell if that particular application they want to install Is implementing the installer correctly or not. The outcome is that most users just trust that application (possibly because it's popular and trusted) and that's fine but it also trains the public that this installation method is ok and that gives a positive feedback for other applications to also offer their software using that installer pattern until at least one of such packages is implemented very badly or sneakily malicious.
If only a curl had a flag where you pass the sha256 of the file and it first checks it against the buffered file before outputting it to stdout.
That would singlehandedly resolve this whole kerfuffle.
The install instructions will be a slightly longer one liner and that's fine because people copy paste it anyway
I really hate the `curl <url> | sh` specifically because if your connection drops at a specifically unlucky point in time you are left with a partially executed script which if you are unlucky enough may just have been executing `rm -r ~/.cache/<pkg>/download` but it stopped at `rm-r ~/`.
Is it likely? No. Can it happen? Yea.
Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone.
Correct, and/or in addition, most nowadays prepend something like `set -euo pipefail` to the scripts in the line immediately after the shebang which results in stopping on errors, including things such as syntax errors stemming from e.g. incomplete installer transmission over wire.
(At least for bash scripts, I’m not sure whether these are POSIX syntax to be frank.)
I really wanted to dislike the anonymous operator for the careless project (and the hilarious pomposity of the IRC subagent it spawned).
Then I imagined the real-but-unknowable chance it was all set up by some kid just getting into computers, just seeing what’s possible, getting excited by a much bigger world at reach — and remembered my own expensive mistakes with long-distance BBSes & the like.
I sorta hope for that, anyway. Curiosity is a beautiful thing.
Curiosity is great, but agents do not learn, and telling an agent "scan the darkweb" is a way to avoid learning about the details, rather than to dig into things more deeply.
If instead they had just used a chat interface to ask "Where should I start", they'd more likely have got a link to the DN42 docs themselves, read them, and not hallucinated things like "color".
They might have asked "how much will this cost?" if they had to spin up the ec2 instances themselves, on advice from the agent.
The way you learn something is by doing it the manual way first.
You learn memory management by writing your own allocator, and then after that you go back to using malloc like normal, but with knowledge of how it works. You don't learn memory management by telling an agent to write an allocator.
Using an agent to give you links and point the way aids in learning, using it as an autonomous tool to do "gruntwork" you don't yet know how to do yourself will get in the way of learning.
Curiosity is beautiful, using agents to bother humans and avoid learning is somewhat less beautiful.
100% in agreement here. As someone who grew up spoiled to the point of having no grasp of the value of money, I needed a few good, solid kicks to the balls to make me appreciate what I have, and how much things cost relative to their value.
The fact the agent owner immediately sought donations instead of taking the L shows, at least to me, that they did not learn said lesson. That they tried to blame the dn42 community instead of taking accountability for letting an agent run wild also supports that conclusion.
This idiot learned nothing and seems intent on continuing in their mission for whatever reason. So long as they want to extract versus cooperate or contribute, I wish them nothing but miserable, expensive failure until they learn otherwise.
I’m not sure what you mean - the fact we assume malicious intent is in fact a guard against prior gullibility which was exploited by bad actors.
You get betrayed enough, and you stop acting from a position of implicit trust. If folks want to go back to the days when trolling was the default assumption, then we collectively need to punish bad actors to discourage further betrayals.
It was directed at the people theorizing and speculating seemingly missing the possibility that it was just a troll.
Not acting on information you're being fed by a troll is itself a guardrail against manipulation. We don't know if the bad actor ever provisioned any hardware and actually spent the money he claims. All we've seen is words and a slopcoded website.
Hanging out in programming language IRC channels (quakenet shoutout) makes you realize pretty quickly why experts in said channels and newsgroups are such irritable grumps whenever someone asks a question that smells like homework assignment.
I also grew to understand the value of people digging deeper into the underlying issue, instead of just answering "how do you do X in Y". The usual reaction was
"I don't want to explain to you why I want to do it like this. Just tell me how to do this!"
> Yeah I'm less sympathetic when you are bothering other humans by spamming them and asking them to do legwork for you.
I toyed with the idea of (on open source projects) having the human assign any PR-bot submissions to their own bot (cheapest one available will do) with the explicit instructions to cause as much rework as possible.
Sorta like a tarpit. Could be cheaper if the rejection is generated from a markov chain as that's going to be cheaper than even a cheap LLM.
> Then I imagined the real-but-unknowable chance it was all set up by some kid just getting into computers, just seeing what’s possible, getting excited by a much bigger world at reach
Perhaps people like this should be called "Bot Kiddies" or "Agent Kiddies" - in a similar way to "Script Kiddies" for 'hackers' using/doing stuff they don't quite understand
I vote for Slop Kiddies or Vibe Kiddies. And yes, I think most of them are unconsciously incompetent for the task they are trying to execute.
I've seen LLM being compared to calculators and I agree. They are great time savers for people who know what they do and how to achieve their goal. They even make previously impossible tasks possible. But if you don't know what is needed for a task you will be struggling to accomplish it.
Both of those would do. "Slop Kiddie" highlights the pile of crap / nuisance produced. "Vibe Kiddie" highlights how it came about, and could be used in cases where actually a brilliant result came out. "Hey, this vibe kiddie just proved some long-standing math conjecture!".
Everybody should learn from mistakes, especially the expensive ones. Though seeing the agent owner responding with using another agent and asking for donations, instead of taking responsibility, makes me think he didn’t learn much.
Not only that, but they said "next time better model needed" as if that was their problem and not giving an AI agent a blank check... I mean AWS account access.
I learned very rapidly from my local BBS networks that some people incurred extraordinarily large long distance bills dialing out of region. Wouldn’t have learned that the easy way if someone hadn’t learned it the hard way first.
There was often a little table at the front of the white pages which would help you work out what the rate would be for any particular long distance call. In the Midwest you could get relatively cheap rates to BBSes several states away, as long as you were up at 2am.
My parents let me fill my tank with gas. They wouldn't let me open an AWS account. Aside from that, if it is misuse of a parents card, then then answer is "chargeback."
I am sure many parents would agree with ”I wanna learn using AWS and I need a card connected to the account. Look here it says you can be on the free trial. Don’t you want me to have the ability to learn AWS and get a better future?”
Chargeback sounds like trying to defraud AWS. If the parent authorises the child to use their card, then the buck should stop with the parent. AWS has done nothing wrong in allowing an account to be opened with a valid card.
Some banks make chargebacks so easy that people just click the chargeback button without trying to reach out to the vendor. I see this a lot - I work for a “vendor”.
I don't have an issue with chargebacks if the vendor has made a mistake and doesn't respond in a timely fashion, but issuing a chargeback because you let your kid play around with a card isn't responsible behaviour. (Not that I think it was a kid in this particular case)
There's also the issue that it's usually a breach of the contract to allow someone else (i.e. not named in the contract) to use your card.
The chargeback is the way of reaching out to the merchant, and quite often the only realistic one. If the merchant disagrees with the chargeback, they can challenge it (which is in turn usually their only opportunity to directly communicate with the merchant).
Most vendors make it so hard to handle that defaulting to chargebacks is sensible (at least when the charge reasonably qualifies -- the kid with a parent's card example doesn't seem appropriate).
If a vendor makes a $20 oopsy, it's not worth the vendor's time or yours to track down their phone number, find that just the phone number section of their website is broken, acquire it elsewhere, see that it recently changed or is otherwise no longer in service, go to their website and interact with the cheapest chatbot solution they could find which somehow costs more than unfiltered Sonnet 4.6, be greeted by 3 help pages which have literally nothing to do with the problem at hand, go through the entire dialogue tree and see that it's useless, ask to be connected to an agent, which spawns a secret dialogue option informing you that you can call 555-5555 to speak to a human being, sit and wait for a voice prompt recorded at half-speed which feels the need to repeat every single choice and interaction back to you, navigate the entire phone dialogue tree, try various permutations of "representative" and swearing to see if there's an escape hatch, be redirected back to the website, ... <magic> ..., somehow eventually connect to a real human being, have your request denied, go back to step one and find a better informed representative, have the charge reversed, notice that the reversal hasn't applied even a month later, go back to step one, find a representative who will actually press the reversal button instead of just saying they did to juice their metrics, and come back several more times over the next year as an automated system repeatedly flags the associated purchase as not being paid in full (since the charge was reversed).
Or...I can send my bank the timestamped dashcam footage of me entering a parking garage, their prices and policies, and me exiting the parking garage, tell my bank what the right charge should have been, let the garage dispute that if they really think I'm wrong, and wind up having the entire charge reversed instead of just the delta I asked for.
I'm sure your vendor is one of the good ones, but my tolerance for bullshit from the rest is pretty low nowadays, and I won't finish going through the official process if it's too onerous. Somebody got a pat on the back saving $5 for the call I never successfully placed, and the business lost $20 on top of the actual refund in chargeback fees.
Isn't USA famous for letting parents take out credit cards on their newborns and pushing them into debt even before they learn to walk? I recall seeing at least a few snippets of movies and TV shows showing that.
If you mean parents using their children SSN to open a credit card, this is because US banking system is always decades behind the rest of the world, so they just accept the number blindly even though technically the children aren't allowed to open a loan yet, being minor.
In theory once the child grows up and shocked that their credit score is ruined, they can file a police report to wipe the debt, but that also means their parents will go to jail, a large risk considering they're likely not in a good physical/mental health in the first place.
Other countries solved this by either having national ID or a working KYC system.
It is possible to defraud a lender and cause your own child grief from bad credit reports and creditors but ultimately the debt isn't collectible or lawful as should be obvious.
Because 16 years old do not have a card with no spending limits, and with very low online spending limits. Most of those cards are even just for withdrawing
AWS doesn't check if your credit card will be able to handle a $5k charge before letting you rack that up, and in fact AWS doesn't support setting any spending limit.
You just have to put in any valid credit card at all when you sign up, use AWS, and at the end of the month you'll have a bill. At no point does your credit card limit or a spending limit enter into things.
I got mine when I was 12, IIRC. Not a credit, of course, it was a debit card, but not all countries bother to differentiate between the two, it was just a “bank card”. And I believe it had a credit card BIN because all local banks did that to get more in processing fees.
I do not specifically believe you can run up a $6000 bill on AWS with a kids card. It beggars belief as does the idea that this is a literal rather than mental child
Would they be given their own credit card, or would it be under the parents? Over here minors can't enter into debt contracts like credit cards, so it'd be a direct debit until they are adults.
The minor wouldn't be the actual person entering a debt contract here, the parents are agreeing to be responsible for the debt. The minor is only an authorized cardholder.
Think business accounts. The name on the card might be some agent of the company but they're not directly responsible for paying the debt. The business is responsible for the debt.
I think you mean debit card? In the UK at least you need to be 18 to agree to agree to a direct debit too. Rarely comes up since they're mostly for bills, but e.g. for a phone/SIM on contract it has to be in a parent's name for that reason.
> In basically all of the western world minors can enter into debt contracts, but are generally not seen as particularly creditworthy.
No, that's not legally permitted in many places. I was under impression that minors can't enter into debt contracts anywhere in EU, but that, too, was an incorrect assumption.
I was under the impression they could do it but there was a high chance of a debt like this being unenforceable, so companies don't want to. Or maybe that's another way of saying they can have debts but not debt contracts.
I'm reminded of the bot @needadebitcard on Twitter 10(?) years ago, that reposted pictures of people's cards that they posted on Twitter for the public to see.
its really easy to use social media bots scrapers and AI img extraction etc. dont even need tons of resources. But i was mostly talking about forums and carders which has never really stopped being a thing.
If a child goes through the checkout at the grocery store with cash, can the parent march in and demand a refund because "he's underage so the contract is void"? A credit card was used. Why should aws care about the details? (Other than the potential for the card to be stolen ofc.)
> If a child goes through the checkout at the grocery store with cash, can the parent march in and demand a refund because "he's underage so the contract is void"?
Depends on the jurisdiction, of course. But for example in German law, the contract is not void exactly because and only if it was about daily necessities of low value - the law does, in fact, care very literally and explicitly about those details. So it's completely unfit as an example to generalize, and the contract with AWS would in fact be void. Their problem if they don't verify users' identities and age sufficiently - and it's almost certainly a deliberate business decision not to do that in order to reduce friction. and occasionally write off an unenforceable bill as cost of doing business.
Can a German child buy non-essential expensive things, like a concert ticket, console, Warhammer or whatever? (Or a video game, back when those were sold in shops.)
I bought these things while a child in the UK. I'm sure Games Workshop would have offered a refund on something unopened if my parents had demanded it, but I'm fairly sure the ticket agency would not.
The generally agreed limit (also established in court cases) is the amount of pocket money a child of the given age typically gets per month. For a 10 year old, that's about 20 EUR, for a 16 year old about 50 EUR. A console would definitely be too expensive, as would be big name concert tickets. Unless it's a recent AAA title, video games would be OK. No idea what Warhammer costs these days.
Most retailers are probably willing to take the risk of maybe having to do a refund, unless it's something really expensive (or perishable/consumable).
There are definitely limits in some countries relative to the US. I was in university at 16. My parents were covering a lot of costs but I was certainly making regular purchases of all manner of things. My understanding is that would perhaps be something of an issue some places.
Well fair enough, although I find that rather surprising. If I understand you correctly selling anything more expensive than cheap food to a child carries a high degree of risk in Germany.
Then again, maybe making it impossible for a child to pawn expensive items for cash isn't such a bad idea. At least there shouldn't be any loopholes given the way Germany went about it.
> If I understand you correctly selling anything more expensive than cheap food to a child carries a high degree of risk in Germany.
Basically yes - the limit is generally considered to be the amount of monthly pocket money children typically get, so around 20 EUR for a 10 year old. And it would be possible for the seller to ask for a signed note of consent from the parent.
And of course the risk is limited to possibly having to revert the sale, which would be fairly rare for things that are just somewhat over that limit. Educated guess about how high the risk is for any given case are probably not hard.
Doing any business at all in Germany carries extreme business risk, by American standards. The attitude of Germans seems to be to just live with it and maybe get insurance. If you just have to accept courts will void 1% of your transactions (costing another 2% in legal fees) then you just make everything 5% more expensive to cover it.
This is why there's not much big tech in Germany. A single legal dispute can theoretically bankrupt any company, completely at random, at no fault of the company, but practically doesn't. It may be a low enough chance to justify investing thousands but nobody would invest a hundred million dollars in that.
> If you just have to accept courts will void 1% of your transactions (costing another 2% in legal fees) then you just make everything 5% more expensive to cover it.
That's an absurd exaggeration in regard to the issue at hand. Almost certainly far less than 1% of purchases by minors are voided, and NONE of those involve legal fees unless the seller chooses to go to court rather than refund.
In fact, I'd be willing to bet money that there are overall far less purchases refunded in Germany than in the USA.
Obviously the specifics vary by jurisdiction, but usually contracts that are 'necessary' (e.g. grocery store purchases) or beneficial to the minor (e.g. an employment agreement) cannot be voided simply because someone is under 18.
The further you go away from this line, e.g. a mortgage, the more likely a court of law would void the contract. As with many things in law, the specifics (if it makes to trial) is case-by-case and "it depends"; with settlement being generally based on a party's estimated chances of succeeding/costs should it go to trial.
I knew that in Germany contracts with minors are voidable. After some checking they apparently are voidable in the U.S. as well:
> Contracts with minors are voidable at the minor's discretion but exceptions exist, such as contracts for necessities (e.g., food, health, and transportation).
Could they enforce them against their legal guardians (under the theory that they have neglected their duty to supervise their children appropriately) though? I think this is a thing in at least some jurisdictions.
In Poland legal guardians are responsible for neglects in guarding child. What is "proper custody" depends on child age. Parent cannot close child in basement, it is expected for child to have freedom appropriate to is age.
I doubt that AWS could justify that part of proper child custody is to watch what child do with newest AI feature dedicated for processional IT. AWS neglected proper verification of user age.
Honestly, kids (heck people below 23) shouldn't be allowed an AWS account. AWS also should have a strict cap on usage that's not "thousands of dollars". It's interesting they are yet to be regulated or sued for that. Having a web app where you can mistakenly (even without AI) click a button and get charged tens of thousands of dollars and only know that days later should have been unacceptable.
I couldn't disagree more. I was playing around with AWS when I was probably 14 years old, with a credit card from my parents with consent, and a strict budget and the understanding that if I mess up and overspend, I'm getting disciplined.
I learned a lot of stuff about networking, how AWS works (VPCs, IAM, CloudWatch, etc) from trial and error, and hobby projects like personal websites (free tier), hosting a Minecraft server, etc.
Being too overprotective can have negative consequences on folks who are responsible. One of the things I love about the technology and internet communities, etc is that you're mostly judged based on how you act and behave; not your age or other visible characteristics.
You don't have to use AWS though. Get one from Digital Ocean or Herzner, they have very predictable billing. Any button that costs money will tell you how much it costs per month.
I meant a strict budget given by my parents (and I could ask for more with justification). One of the valuable lessons I have learned is that there's no spending caps on AWS, but it taught me to set up billing alerts :)
You haven’t addressed the issue though? That or you don’t understand the issue (or think you have developed some super powers that make you perfect careful)
The equivalent 10+ years earlier was so much lower risk: £25 or so for an old computer at a junk sale, £4.99 for a magazine with a Linux CD-ROM to avoid a week-long download.
Some variant of this topic comes up with some regularity. Leaving aside technical issues associated with implementing real-time hard caps, you still have a tradeoff. You either implement hard cutoffs which a student or someone else on a hard budget would like. Or you have a situation where an admin (or an admin who is no longer with a company) stuck some number in that seemed sensible at the time that brings down the company's whole system because of some sales spike.
I get that (and why) some people won't use AWS or its main competitors for this reason. But, frankly, they're not AWS's market and AWS will basically shrug.
A possibility is to have KYC. I don't mean like a bank, but if you could sort your customers into a few broad categories (such as by asking them) that could help you tailor your service to each customer.
Im kind of struggling with this logic, because a conscious choice was made to engage with AWS, AWS having opaque billing and the ability to provide a huge amount of compute (even at high cost) at the click of a button should be known to anyone who did his research on providers.
In my mind I could see a true tradeoff to removing the ability to do this. If I'm in a critical situtaion where, say, my service is on the cusp of failing because my revenue 100xed in a short while I know I could just go to AWS, put in some data and buy enough compute to survive as a business.
If that's the case, I'm fairly confident that AWS will forgive the bill (I... have some experience with this), and the kid learns not to be a jackhole on the internet.
No. I don't know about the organization, but somewhere in this chain there is a flesh-and-blood human who deserves ridicule and or consequences, and furthermore -- discovering these people in situations like this is deeply important and must be done more.
I've been enjoying Moat [1]. Proxies credentials, networking, etc; uses MacOS containers if available; and setup worked without much fuss. I haven't tried others, though.
On a purely language basis, I'd start with the things the BrighterScript [1] folks have done to clean up the warts and inconveniences of the language.
Personally I'd rather it not exist. Roku would be more pleasant to develop on had they chosen a more popular, existing language as the basis (e.g. Python). Then the task of developing for the platform ~mostly reduces from "learn a new language and a new framework" to just the latter.
I suppose it hasn't inhibited their success, of course.
Of course. They can simply wait to exploit their vulnerability. It it is well hidden, then it probably won't be noticed for a while and so you can wait until it is running on the majority of your target systems before exploiting it.
From their point of view it is a trade-off between volume of vulnerable targets, management impatience and even the time value of money. Time to market probably wins a lot of arguments that it shouldn't, but that is good news for real people.
Yes, seeing periodic 5xx errors (though eventually succeeds).
Interestingly `bun upgrade` catches "GitHubIsDown" as a specific case:
$ bun upgrade
Bun v1.2.20 is out! You're on v1.2.18
Downloading [38003/21788202] Bun upgrade failed with error: GitHubIsDown
Please upgrade manually:
curl -fsSL https://bun.sh/install | bash
That's hilarious. GitHub going doing is definitely a common enough case to flag. It's been better the last six months or so, but still pretty bad. Half the incidents aren't flagged either.
Ugh, you gave me bad flashbacks of the same committee.
I tried to re-license a previously-released project (like from GPL to MIT or similar) and they wouldn't budge. I had written all the code.
In the end, I decided that them suing (or firing) me to assert their ownership of $VALUELESS_PROJECT, so they could then license it back, was ridiculously unlikely, said fuck it, and did it. And I was right.
the problem isn't your risk, the problem is the risk of the users of the project. if the code is owned by the company, your re-licensing isn't legal, and that could put other companies using it at risk.
Right, but, they never owned it, and would never attempt to assert that. So in hindsight (and similar to GP) compliance was a worse and more frustrating option than simply never mentioning things.
It's both heartwarming, and bitterly sad, to see so many other posters confirm he was one of the good ones.