They're using flakes.
Corbin
I don't see why I would use this instead of vim. I see that you think it's a different approach, but it looks like a fairly standard rich-text editor to me; what am I missing?
You need SRE concepts. First, if you break it then you fix it; in a system where anybody can make a change, it's the changer's responsibility to meet service objectives. Second, if your boss doesn't find that acceptable then they need to appoint a service owner and ensure that only the owner can make changes; if the owner breaks it then the owner fixes it. Third, no more than half of your time should ever be spent fixing things; if something is constantly broken then call a Code Yellow or Code Red, tell your service users that you cannot meet your service levels, and stop working on new features until the service is stable again.
Under no circumstances, ever, should anybody stay late. There should only be normal business hours, which are best-effort, and an on-call rotation which is planned two months in advance. Also, everybody on call should be paid hourly minimum wage on top of salary for their time.
Nothing has really changed in the past four months. If you really disagree, feel free to try my vibecoding challenge; it closes on March 1, but that's surely no obstacle for the amazing vibecoding chatbots which didn't exist in November and only recently evolved. I did all three challenges by hand and no vibecoder has yet been able to match my mediocre, lackluster work.
I don't understand why I would choose this as an anti-corporate license instead of AGPLv3, WTFPL, or CC-BY-NC-SA; in general, we want corporations to not use our software rather than accept the license conditions, and this license isn't scary enough. I also don't think that this tastes like it was written by legal professionals; how did you generate the text of the license?
It isn't the first time that the advertising requirements were used to chill speech. It doesn't matter whether there was a ban; what matters is whether speech was effectively prevented. "There is no God. Now stop worrying and enjoy your life."
You've reinvented one of the two reasons that Project Xanadu failed: micropayments have very high overhead relative to the content being paid for. (The other reason is that there literally aren't data structures which work like Xanadu's data model.)
Further, where does money come from? You're sketching a system where money has relatively high velocity, but it's all paying for content, which has marginal cost to distribute; how does money get into this system in the first place? This is why Bitcoin's currently on a trend to zero; once everybody realizes this problem, the system collapses from lack of faith.
I hope that thinking about this for a bit will radicalize you further towards the understanding that a universal income and artists' stipend is the economically-sustainable way to compensate artists, rather than forcing folks to swap scraps of digital coinage.
From the perspective of somebody who's actually hacked on Linux: Most Linux maintainers, like most programmers in general, are full of machismo stemming from the inherent difficulty of writing C. It is extremely difficult to write correct C and nobody can do it consistently, so those maintainers are heavily invested in the perception that they are skilled with C. Rust is much easier to write and democratizes kernel hacking, which is uncomfortable for older maintainers due to the standard teenagers-vs-parents social dynamics. Worse, adapting various kernel interfaces so that they are Rust-friendly has revealed that the pre- and postconditions of interface methods were not known before; there is existing sloppiness in the kernel's internals which is only visible because of Rust-related cleanups.
Note that Linux is not a GNU project. GNU's kernel project is GNU Herd. "GNU/Linux" refers to Linux userlands populated with GNU packages. It's important not to be distracted by this; the kernel is agnostic towards userland and generally is compatible with any loadable executable that uses Linux's public syscall interface, so the entire discussion of Rust in the kernel is separate from anything going on in userland.
Most siblings are wrong! PRs written in Rust can be rejected. There are already multiple non-C languages in the kernel. Rust is sufficiently available on the platforms where it will be required for building kernel. Maintainers are only added after they have shown themselves to be socially reliable and they can be removed by other maintainers if they are unresponsive. The only correct sibling points out that Rust is different.
This looks like a prompt-driven approach. As such, it will always be watered down by reinforcement learning in longer contexts. Also, the entire thrust of the prompt is ridiculous and would only work in a science-fiction novel; its metaphysics are fairly wrong. But it looks like it will be even more sycophantic than the default prompt for the cloud products you compared, so it's not really surprising that some folks find themselves attracted to it.
@eleijeep@piefed.social You had a couple months. At this point, I think that you've failed the challenge. I know that there's a lot going on in the world, but frankly I doubt your commitment to dick-measuring contests on Lemmy if you're not even able to write a bug-free JSON recognizer in C in eight weeks. I understand why you wanted to remain pseudonymous!
Let us all learn a lesson from eleijeep: writing correct C is very hard and probably can't be done on-demand. Correct C isn't a party trick.
BadRAM specifiers can apply to stripes of memory corresponding to certain physical hardware failures. The memmap hack only allows for contiguous allocations. BadRAM's intended for repurposing consumer-grade RAM that might normally be thrown out, not for reconfiguring motherboards that have strange layouts.
There's no topic to engage upon. There's merely a fascist vendor trying to enter a community space from which they were already ejected.