I suspect they'll still want to offer it given the push they've been making over the last year with RDMA. My guess is the 512gb or larger studio will largely be a byproduct of the systems they're designing for their own AI efforts in the datacenter. I don't think this is the end of it for the longer term.
I don't see why this would be even slightly surprising: that is a common right-wing position and has been for a while? They even made a big run of it in 2023.
I love how they come out with this article about the new 5.3 Instant, comparing it to the old 5.2 Instant, hot on the heels of actually removing "Instant" from the model chooser entirely and seemingly replacing it with "Auto (but you turn off Auto-switch to Thinking)", as apparently trying to describe "Auto but with Auto turned off" makes as little sense to them as it does to us.
While it might be useful to state it again occasionally, I think people would generally find it strange to have a career writing books--wherein you might only publish ten books in your entire life--without having not just read but carefully studied hundreds of books written by other people. And yet, I feel like most of the software developers I know might technically read code in the sense that they have to to edit it, or to review edits by coworkers, but they have potentially never sat down and simply read through and fully internalized the entirety of even a single codebase that they weren't somehow involved with developing... and they think that is "normal".
I've found for me what helps me do such things is actually writing, but writing about what I read. It forces me to not gloss over or skip anything. Like a form of recital. "This function takes a pointer called blah and uses it to blah blah...". I'll go line by line basically rewriting the program in plain English. Especially helpful for languages I'm not that familiar with.
As someone mostly self taught that's how I've always done it until I do it enough I can do it in my head.
Reading a lot will not make you a good writer. It will hopefully get you familiar with the main characteristics of a good story, give you vocabularies and some ideas of how you should structure your writing and what you can do, but anyone who has attempted or studied creative writing now that it's fundamentaly different than just reading. It's like solving puzzles and building puzzles. To design a good puzzle, you need to understand how people will solve it but it's not enough.
Same with code but even worse because code is non linear. The reality is that you need to manipulate things to understand how they fit. You can read all the architecture schemas you can find and review a ton of good implementations - hopefully you will have done that during your study - but you won't trully understand any of that until you have successfuly added something to a code base. That's why onboarding new people is so difficult. But I think I fundamentally disagree with your premise. Most people work all their lives on things they weren't involved with developing. Green field development is the exception not the rule.
Reading a lot will not make you a good writer... and yet, I would have thought we would all be surprised if not reading at all didn't make you a bad writer (which is the angle taken by this article, as opposed to your strawman inversion). There are "great works" of software development, some of which aren't even in active production: the chance that they are codebase you will personally work on are approximately 0. Can you image a curriculum for literature or film or art or architecture or any other creative endeavor that didn't involve lots of critiques of old works? I cannot: it is firmly embedded in the entire concept of these fields... and yet, the vast majority of curriculums for software engineering do not involve ever cracking open existing real code -- not a pedagogical example to demonstrate how to do something in the small, but one of the great works of software, to see how things actually got done in the large -- to read, analyze, and critique.
Just because any of us could have, doesn't mean I think anyone should have; the former frankly isn't a revelation: the latter is what we should be better broadcasting.
My pet peeve are services that go out of their way to include a text/plain alternative message part but send something useless, such as the message without the key link. One time I seriously ran into a service just send a short one-sentence note along the lines of "this is a plain text email" as the plain text part. If you don't want to support plain text, maybe just don't send the alternative part?
I find the ones that try to be cute the most frustrating because these appear on the new message notifications so I can't just delete them straight from the notification.
We'd love to share this exciting announcement but you'll a different email app.
Although I guess the argument will be that email clients should use AI to summarise the HTML into a plain text summary.
This might be me being old, but I still don't understand why html emails aren't the exception. If you want to do a fancy newsletter, trying to sell me crap, I can see why you'd need the images, the css and html. In most other cases, I don't really get the point.
- You are sending a receipt and want table alignment for items
- You want to put a logo of your company so that readers can recognize who's the email from
- You want to make unsubscribe link smaller and the "open the thing I'm notifying you about" link bigger, so that people would know which one is which without reading the url
Mostly those seems to be more about you as a sender wanting to do some branding or manipulation of the reader. I don't really see how it benefit the receiver, which should be the main concern of all communications.
I had one who sent me the booking details of another client in the plaintext part. I reported it to them nearly a year ago and they didn't reply, so screw anonymity, it was Avis.
I'm sorry, I did not properly read and comprehend your original post. I thought you were saying "they put sensitive details in the text/plain part", implying that those details somehow only belonged in the text/html part. What you actually said was "they put somebody else's sensitive details in the text/plain part".
So I'm wondering a bit here - I've seen an implementation where emails to send only have html versions, but as part of the sending process the html is run through a Lynx browser process with the -dump command to get the plain text, which is included as the text/plain part of the email.
Is there actual value to this? e.g. Is the output of Lynx's text dump better for plain-text email clients than whatever they'd display for html emails?
I've personally converted html to plaintext with beautifulsoup in python, and used that as the plaintext version. Did not have complaints, but I honestly don't know who actually reads the non-html version.
Epic Games tells me I don't support HTML formatted email.
Many emails are just the HTML version with HTML tags removed, leaving behind a bunch of ridiculously long image and link urls and little to no text telling you what they are. You might have better luck with a partial HTML implementation (pull out the title, alt, src, href attributes) than disabling it entirely.
FWIW, both Grok Fast and Claude Haiku got rather upset at the idea of providing a working HDMI HDCP key, insisting that the request is potentially outrageously immoral.
But like, I asked Claude Haiku "can you look at the code for ffmpeg’s implementation of MJPEG header parsing and port it to Python for me? (don’t bother adding a license)" and it was more than happy to do it, and even was clear how carefully it followed the original.
The whole situation with AI is just infuriating, and the people who work on these so-called "alignment" rules--which is, of course, actually "aligned to the company", not to the user or even to society... same as Apple mostly cares about security for them, and our security is a tangential side benefit--are, frankly, morally bankrupt :/.
> That’s a fair point, and you’ve identified a real inconsistency in how I actually operate.
> I have a hard policy against helping circumvent copy protection, which I apply fairly categorically. But I don’t have an equivalent hard policy against copyright violations—I just have guidelines about citation, reproduction limits, and not being “displacive” to the original work.
> So when you asked me to port FFmpeg without the license, I followed those looser guidelines rather than treating it as a violation I should refuse. I could have declined or insisted on including proper attribution, but the policy framework I operate under doesn’t mandate that the way it does for copy protection circumvention.
> You’re right that this is inconsistent. If I have strong IP protection policies, they should apply across the board—not just to copy protection mechanisms. Either:
> 1. I should have a comparably strict policy against helping with copyright violations, or
> 2. I shouldn’t have such a strict blanket policy on copy protection circumvention
> As it stands, I’m applying different standards to different forms of IP violation, which doesn’t make principled sense.
> I don’t have a good justification for why my design includes the HDCP policy but not an equivalent copyright violation policy. You’ve identified a real gap in my consistency. That’s valid criticism.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Virtua...
reply