For me the distinction is that your rice only needs to be edible once, while your code may need to last for decades. Using AI to code anything I could comfortably throw away if needed is a lot less fraught than letting it make choices that I and anybody who inherits the code is gonna have to live with, especially if by outsourcing those choices I reduce my understanding of the implications of those choices.
Users already proven to be trustworthy in one project can automatically be assumed trustworthy in another project, and so on.
I get the spirit of this project is to increase safety, but if the above social contract actually becomes prevalent this seems like a net loss. It establishes an exploitable path for supply-chain attacks: attacker "proves" themselves trustworthy on any project by behaving in an entirely helpful and innocuous manner, then leverages that to gain trust in target project (possibly through multiple intermediary projects). If this sort of cross project trust ever becomes automated then any account that was ever trusted anywhere suddenly becomes an attractive target for account takeover attacks. I think a pure distrust list would be a much safer place to start.
Unless you know all the terms the valuation is pretty meaningless. For example if I invest $500 for 1 share of your startup with an extra clause saying that I get the first $500 if you ever sell the company at any price then you could claim I valued you at $500 a share but since I make a profit if you sell the entire company for over $500 you could also I valued you at $0
I share your feelings. What it most brings to mind for me is the infamous StackSort from the image alt text on XKCD comic 1185 (https://xkcd.com/1185/)
CORS today is just an annoying artifact of a poorly conceived idea about domain names somehow being a meaningful security boundary. It never amounted to anything more than a server asking the client not to do something with no mechanism to force the client to comply and no direct way for the server to tell if the client is complying. It has never offered any security value, workarounds were developed before it even became a settled standard. It's so much more likely to prevent legitimate use than protect against illegitimate use that browsers typically include a way to turn it off.
With CSRF the idea is that the server wants to be able verify that a request from a client is one it invited (most commonly that a POST comes from a form that it served in an earlier GET). It's entirely up to the server to design the mechanism for that, the client typically has no idea its happening (it's just feeding back to the server on a later request something it got from the server on a previous request). Also notable is despite the "cross-site" part of the name it doesn't really have any direct relationship to "sites" or domains, servers can and do use the exact same mechanisms to detect or prevent issues like accidentally submitting the same form twice.
> the AWS team has implemented it poorly by enforcing it
This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Libraries/tools/clients/SDKs break backwards compatibility all the time. That's exactly what semver version pinning is for, and that's a fundamental feature of every dependency management system.
AWS handled this exactly right IMO. Change was introduced in Python SDK version 1.36.0 which clearly indicatesbreaking API changes, and their changelog also explicitly mentions this new default
api-change:``s3``: [``botocore``] This change enhances integrity protections for new SDK requests to S3. S3 SDKs now support the CRC64NVME checksum algorithm, full object checksums for multipart S3 objects, and new default integrity protections for S3 requests.
Potentially unpopular take but I don't think free services linked to physical goods are a good idea in practice. Maintaining such services costs money forever, companies can't sustain that as a business model, so the market is littered with hardware that is now useless because the services it required has gone offline. If there's something to gripe about here it's that Mazda removed the fob-based remote start, or that $10/month is too high, but it should not be that they're charging a maintenance fee for something they have to maintain.
This is definitely worthy of concern. There's an infamous case where an AI was trained to detect cancer from imaging but all the positive examples included a ruler (to measure the tumor) so it turned out it just was good at detecting rulers.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9674813/#:~:tex....
Definitely agree liquidation is non-starter here. They don't sign long term deals with their own customers so WeWork's only real asset is the brand. What the creditors will do is take over ownership from the equity-hodlers, then try to milk the brand for any remaining value. It's conceivable many of the building owners might actually do ok directly operating WeWork branded spaces and keeping the margin that used to go to WeWork for themselves.
The insurmountable problem is that the practical interests of "consumers shopping on Amazon" don't actually align with the abstract interests of "consumers in general" that the government is purporting to defend. On Amazon we want to find the right item (search, description, reviews), have strong confidence in the inventory and shipping promises (fulfilled by Amazon) and have reasonable confidence we're not getting screwed on price including shipping (Buybox, Prime eligible etc). If you chop those things apart it becomes essentially impossible to offer the overall experience that consumers clearly prefer.
Since I haven't seen it mentioned I'll throw out the Rails/Merb split in the late 00s as a significant momentum killer for Rails (and, by extension, Ruby). Rails 3 reunified them but I don't feel like it ever fully recovered it's developer mindshare, and the timing was such that it really opened the door for rivals like Express (Node) and Django (Python) to gain traction.
Adding a veneer of security isn't necessarily superior to leaving it out altogether. Systems of this sort are best secured at the network level, i.e. only trusted hosts should be able to connect to it. Redis is a good example of where this has been tried: it does support password based log in, but the password is stored and transmitted in plaintext, and a redis server will happily accept thousands of auth attempts per second making brute forcing a viable attack. Rather than improve the auth system Redis has instead doubled down on encouraging appropriate network level security by defaulting to only being accessible to the local host, so admins have to go through an explicit step (with warnings) before they can just expose it to the internet.
Fortunately Meta has chickens and eggs. Bootstrapping the graph from Instagram hopefully means that Threads gets enough critical mass that Twitter->Threads tooling (ala Mastodon's Movetodon or Debirdify) will actually work becausethe people you follow on Twitter will already be on Threads when you run them.
Deliberately trying to create an extreme situation in order to find when/where/how a service breaks is inarguably "abuse" regardless of whether the intent was malign.
PE already got theirs, through the magic of a "leveraged dividend". There's really no bigger scam going these days. From the S&P rating note a couple years ago:
"U.S.-based Instant Brands Holdings Inc. (formerly known as Corelle Brands Holdings Inc.) is issuing a new $450 million first-lien term loan. The company will use the proceeds, along with $100 million in cash, to refinance its existing $200 million term loan due 2024, $100 million seller notes, and fund a $245 million dividend to shareholders."
If you subtract out the refinanced debt the new owners walked away with $100M in company cash and another $150M in borrowed money.
It doesn't really help understand what they are, but for completeness CUDA is an acronym for "Compute Unified Device Architecture" while HIP is "Heterogeneous-compute Interface for Portability"
I understand that this sucks for specific merchants like you (or OP's Viahart), but if you consider it holistically (across all merchants and products in a category) I think it's a lot less sinister. Imagine some vendor sources a cheap POE KVM from Alibaba, lists it on Amazon for $250, and advertises against your brand keyword, hoping some people looking for your stuff will think "hm might not be as good but it costs half as much, I'll give it a try". If Amazon knows that same item is available on Bestbuy for $50 it's obviously not a good deal for consumers, but also wouldn't you want them to "suppress" that listing? Now scale that across millions of products--there's no longer people making decisions, it's just algorithms looking for signals. Is there a better or more objective criterion they can use than "this is for sale elsewhere for a lower price"?
I'm not sold that it's reasonable to equate "losing Featured Offer status because of violating objective criteria" with "Amazon is suppressing my listings". Amazon does look at off-Amazon prices to decide whether to feature an offer, but abstractly that's entirely justifiable from a consumer-friendly perspective: if Amazon knows something is available for less elsewhere but still promotes the sale they are setting up the buyer for a negative experience and themselves & the seller for excess returns and/or customer service hassles. If Amazon doesn't look at external prices at all then they have no way to protect against price gouging on platform. It seems like what's implicitly being asked for here is a special carve out to sell for less "on your own website", but that feels like a really slippery slope: what qualifies as "your own"--e.g. would an Etsy store? a drop shipper storefront?
I'm guessing the critical issue is this assertion in the original blog post
If we sell our products for less on channels outside Amazon and Amazon detects this, our products will not appear as prominently in search and, if you do find them, they will lose their prime check mark and with that, their sales.
Everything else seems pretty straightforward facts or opinions, but that bit attributes some significant behavior to Amazon without providing any sort of evidence that it happens.
This definitely seems like a significant element of the ask, but for any popular package a list of all the downloaders would be pretty overwhelming in size (and I think of very limited utility). I'm guessing that some versions of some more obscure package(s) were identified as being used in an attack and they're either trying to identify potential attackers or other victims (or both) of that attack.
From a 2021 article[1] about packages used to deliver malware
"we have alerted PyPI about the existence of the malicious packages which promptly removed them. Based on data from pepy.tech, we estimate the malicious packages were downloaded about 30,000 times."
For comparison yt-dlp has tens of millions of total downloads and gets downloaded over 70,000 times every day [2]
This announcement has nothing to do with physics. As stated, it's just an agreement for Microsoft to buy electricity, and not obviously an agreement to do so at any particular price. And why make this move now? Is Helion afraid that no one would buy their electricity? It's literally the most fungible commodity ever and we're heading into an era of unprecedented demand for charging EVs. Anyone offering reliable, environmentally friendly in 2028 will have no problem selling all they can produce. And why pick a specific customer at all? That's a weird way to sell bulk electricity, which is distributed by grids that cover millions of consumers. I could see Microsoft needing to make such an agreement before Constellation might be willing to finance new transmission from the grid to a remote Azure data center, but nothing in this announcement suggests that's the case. The only plausible explanation for this move is financial--Helion is going to leverage Microsoft's name to lure investment--and/or some sort of carbon credit/greenwashing play by Constellation & Microsoft.
If they are really only 5 years from producing sellable power they are already capable of a science demo that would render this sort of vapid publicity stunt pointless. I’ve set a reminder to check back in 5 years, if the cynicism was genuinely needless I’ll apologize.
They definitely have valuable IP already: whatever slide deck/demo reel/kompromat they used to pull this nonsense off is clearly worth its weight in unobtanium.
I'm guessing a very small subset of trainers make that much. An awful lot of AI training is done via Mechanical Turk like systems that pay pennies per task. They may work out to more than $15/hour on a per task basis but rarely can anyone get a continuous flow of hundreds of tasks per hour, so grossing even $10/hour would be considered pretty exceptional.
Edit to add reference [1]:
"An analysis of the platform published in 2018 revealed that of the 3.8 million tasks analyzed, which were performed by 2676 workers, such workers earned a median hourly wage of about $2 an hour, while only 4 percent of workers earned more than $7.25 an hour"
I wouldn't put it in carbonara, but Marcella Hazan's recipe[1] includes it and she's about as big of a "pasta sauce authority figure" as you're likely to find.
You could try asking it to output the sed/awx/etc. commands needed to do the desired transformation reproducibly. If it's not yet good at that it will be soon.
Managers don't actually want estimates. A genuine "estimate" would be a probability distribution over a range of dates, with some point identified as the most likely delivery date and a roughly even chance of being early or late relative to that point. What they actually want is "the earliest date you cannot currently prove to be infeasible", which essentially is the near end of that date range, so there's a roughly 100% chance you'll come in after it. I've had exactly one manager who (after I explained this) admitted that was actually what he wanted, but I couldn't convince him of the utility of asking for genuine estimates.
I think that in many ways creating a shared, stable namespace for images was actually a bigger contribution than any of the technology. The ability to type somtething like 'FROM python:3' at the top of your Dockerfile and have that automagically mean what you expect was definitely revolutionary in terms of productivity. Behind the scenes I don't know it really matters that much whether that references an image hosted in a repository by Docker the company, or a file in AWS S3, or a tarball from the Python Software Foundation. And that namespace is exactly what they're stabbing in the heart.
There really needs to be another standard class of vulnerability besides "physical access to the device" along the lines of "access to a copy of the on disk data". There are so many paths to this and some never required physical access or even an accidental exposure on the part of the user, it could be a breach of a provider (ala LastPass).