> What principles and values of the open source movement are protected by staunchly refusing to allow "source available" to call itself open source?
The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?
I know that everyone thinks of Big Tech absorbing your project into their SaaS when they do this, but there are other ways (say AGPL) to combat that. OSaaSy seems to me to be essentially a "give us your code for free, and you can self host it, but don't dare to charge $$ for it or else!" license.
Now you're bringing lawyers into the picture for anyone who's hosting your software on their servers. It's very reasonable for a SaaS company that wants to defend its moat, but it's not Open Source.
Nowadays, most modern computers, from cellphones to mainframes, provide floating point based on the 8087, so I consider the 8087 one of the most influential chips ever created.
That.... seems like a stretch. Does x64 even support the legacy x87 stack anymore? Certainly no other major architectures worked like that.
Because people make them and people make them for profit. incentives make the product what it is.
an LLM just needs to return something that is good enough for average person confidently to make money. if an LLM said "sorry I don't really know" more often it would make less money.
I love all the work that Bruno puts out there. His design and engineering skills are next level.
There are so many talented creatives using WebGL/WebGPU that I've recently launched WebGL.com / WebGPU.com, where I'm dedicated to bring together the community of creatives (designers, coders, AI/ML, etc.) pushing the boundaries of the web.
Would love to see what you would like to see (e.g. tutorials, demos, etc.)
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong
Prove it. Present any robust and complex system that was vibe coded and the prompts used to generate it.
Nah, LLMs and stable diffusion are being used everywhere by everyone hardcore.
I work at a coworking space. Most of the folks I've worked alongside had active chats in ChatGPT for all sorts of stuff. I've also seen devs use AI copilots, like Copilot and Codex. I feel big old when I drop into fullscreen vim on my Mac.
AI art is also used everywhere. Especially by bars and restaurants. So many AI happy hour/event promo posters now, complete with text (AI art font is kind-of samey for some reason). I've even seen (what look like) AI generated logos on work trucks.
When "starve the beast" wasn't killing government fast enough, they pivoted to "we need to make sure it's incompetent, corrupt, and distrusted one way or another."
Turn Your Beloved Pet Into a Masterpiece with PetArtist.ai
Your pet isn't just an animal—they're family, a best friend, and a constant source of joy. Now you can celebrate that bond with stunning AI-generated artwork that captures their unique personality in ways you never imagined.
PetArtist.ai makes creating professional-quality pet portraits effortless. Forget complicated prompts or expensive commissions that take weeks. Our intelligent platform transforms your favorite pet photo into breathtaking art in just seconds. Whether you have a regal cat, a playful pup, a curious rabbit, or any furry friend, we'll turn them into the work of art they truly are.
Why Pet Owners Love PetArtist:
Choose from over 20 stunning artistic styles—from classic oil paintings and watercolors to modern pop art and fantasy themes. Our curated template library means you don't need any design skills or creative experience. Simply pick a style that speaks to you, upload a clear photo of your pet, and watch the magic happen.
Every portrait is delivered in crystal-clear 4K resolution, perfect for printing and framing. Imagine your pet's portrait hanging proudly in your living room, or gifted to a fellow animal lover who would treasure it forever.
The Perfect Gift for Any Occasion
Birthdays, holidays, memorials, or just because—custom pet art creates lasting memories. It's the thoughtful, personalized gift that pet parents truly appreciate.
Ready in Seconds, Cherished for a Lifetime
Our streamlined four-step process takes you from photo to finished artwork in moments. No waiting, no hassle, no artistic expertise required.
Join thousands of happy pet owners who've already discovered the joy of AI-powered pet portraits. Visit PetArtist.ai today and give your furry companion the artistic tribute they deserve.
Your pet is one of a kind. Their portrait should be too.
Surveillance capitalism is going to swing around to full communism.
Airfare, hotel rooms, now even groceries will have their price adjusted based on ability to pay. Getting a raise will have no impact on one's life, as all prices will automatically increase to absorb the additional income.
Honestly, I think this is a valid viewpoint, but perhaps C is too low level. The bottleneck in generating code with LLMs tends to happen at the validation step. Using a language that has a lot of hard to validate footguns isn't great.
While I am not a big fan of Rust, the philosophy is likely useful here. Perhaps something like it, with a lot of technical validation pushed to the compiler, could actually be really useful here.
Getting rid of the garbage collector with no major increase in human cognitive load might actually be a big win.
A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript.
There will be small niches leftover:
* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.
* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.
* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.
* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.
> DHH's choice of license reacts to a real pressure in open source: many companies make real money from open source software while leaving the hard work of building and maintaining it to others.
If you don't want start a business and make real money from your software then denying that to others is antithetical to the concept of open source and free software.
That being said; I have no issue with any developer choosing any license they want -- it's their software and therefore it's their right. But calling it "open source" when it specifically forbids certain use-cases is just wrong. DHH wants his cake and eat it too.
There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every platform.
Rust worded in its initial guarantee that usize was sufficient to roundtrip a pointer (making it effectively uptr), and there remains concern among several of the maintainers about breaking that guarantee, despite the fact that people on the only target that would be affected basically saying they'd rather see that guarantee broken. Sort of the more fundamental problem is that many crates are perfectly happy opting out of compiling for weirder platform--I've designed some stuff that relies on 64-bit system properties, and I'd rather like to have the ability to say "no compile for you on platform where usize-is-not-u64" and get impl From<usize> for u64 and impl From<u64> for usize. If you've got something like that, it also provides a neat way to say "I don't want to opt out of [or into] compiling for usize≠uptr" and keeping backwards compatibility.
> I do think we need more Source Available licenses in the world. Certainly I would greatly appreciate being able to browse the source of the many proprietary software systems I've administered over the years.
Yeah. Releasing a project under a source-available proprietary license and calling it Open Source, or doing a rugpull and changing an established Open Source license to a source-available proprietary license, is the kind of thing that causes the most grief. If you release something under a source-available proprietary license and make no pretenses about it being something else, and the alternative was not releasing it at all, it's a (slight) improvement.
Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.
> To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.
I feel like this is a completely different conversation, but this is just as much a misunderstanding of what open source is as DHH's.
As long as the code is under BSD or GPL, you are free to take it as-is and do what you want with it. You could run your commercial service using it. You can certainly write patches and apply them to your own servers. You could even email the maintainers with them -- worst case is that they will ignore the emails!
Open Source does not guarantee that your contributions will be accepted or merged back to the project -- indeed, if you think about it, that would be absurd. I might want some random thing in the Linux kernel, but the maintainers will always have the final word on whether they want my patches or not.
The O'SaaSy license says that (essentially) 37Signals will sue you if you try to host this on your own servers, and try to sell it as a service. That's totally different, and a legal rather than a technical hurdle.
AV1 is still worse in practice than H.265 for high-fidelity (high bitrate) encoding. It's being improved, but even at high bitrates it has a tendency to blur.
video decoding on a general-purpose cpu is difficult, so most devices that can play video include some sort of hardware video decoding chip. if you want your video to play well, you need to deliver it in a format that can be decoded by that chip, on all the devices that you want to serve.
so it takes a long time to transition to a new codec - new devices need to ship with support for your new codec, and then you have to wait until old devices get lifecycled out before you can fully drop support for old codecs.
