Skip Navigation

Posts
407
Comments
271
Joined
3 yr. ago

  • I actually asked chatGPT about a specific issue I had and solved a while back. It was one of these issues where it looked like a simple naive solution would be sufficient, but due to different conditions that fails, you have to go with a more complex solution. So, I asked about this to see what it would answer. And it went with the simpler solution, but with some adjustments. The code also didn't compile. But it looked interesting enough, for me to question my self. Maybe it was just me that failed the simpler solution, so I actually tried to fix the compile errors to see if I could get it working. But the more I tried to fix its code the more obvious it got that it didn't have a clue about what it was doing. However, due to the confidence and ability to make things look plausible, it sent me on a wild goose chase. And this is why I am not using LLM for programming. They are basically overconfident junior devs, that likes mansplaining.

  • This is obvious for people who understand the basics of LLM. However, people are fooled by how intelligent these LLM sounds, so they mistake it for actually being intelligent. So, even if this is an open door, I still think it's good someone is kicking it in to make it clear that llms are not generally intelligent.

  • That's why it felt very early to have used it before it was default, I mean before 2016 felt too early for me... But it was way before Covid, so I'd say around 2017.

  • I know I have used it since Fedora made it default in 2016. I think I actually used it a while before that, but I don't have any thing to help me pin down the exact time.

    Since I only use Intel built-in GPU, everything have worked pretty well. The few times I needed to share my screen, I had to logout and login to an X session. However, that was solved a couple of years ago. Now, I just wait for Java to get proper Wayland support, so I fully can ditch X for my daily use and get to take advantage of multi DPI capabilities of Wayland.

  • That is the boring part when projects gets more mature...

  • It was a joke

  • No, that is not all the idea. You might have that idea, but it is not a basic idea at all. To keep something open (as in open source), you must put restrictions that prevents it from closing.

    A government is not more free just because it lacks any restrictions, about becoming a dictatorship. It is just less restricted at this point in time. To ensure a free society, there needs to be restrictions in place that ensures it stays free. The same applies to software.

    Many seems to believe that less restrictions means more free or open, that is not true. It is just less restricted.

  • No, I think you missunderstand.... A joke is supposed to be funny.

  • Can someone explain the benefit of letting AWS use your product, then throw resources at it to improve it to get and advantage over your product, basically providing a much better product to their users than you would be able to. But they do it without any need to contribute back. I don't see the benefit of this to the opensource community at all, but people here seems to be quite passionate about it so you must see this differently than I do. So, please explain your view on how such a situation is beneficial to the OpenSource community.

  • I suggest an alternative title to this post: AWS employee is mad since Redis change license to prevent them from leaching

  • Didn't they switch to a license with stronger mechanisms to keep the source available? SSPL, is basically AGPL but have even stronger protection from large corperations to use the code in their data centers without contributing the changes back. This is basically a move to prevent AWS/Google/Microsoft/et al, from leaching on the contributors work without giving anything back.

    Or am I reading this wrong?

    EDIT: Note, that the Mastodon account is to an AWS employee.... so for him, this might be bad, since it no longer allows them to have their own internal fork without contributing back. Now, they will need to use a real for and maintain that them selves without leaching on the redis contributors.

  • If you think this is bad, then you should make sure to use copyleft licenses.

    EDIT: Just read the details, and it seems that this is just what they did. SSPL is like AGPL with a stronger SAAS is distribution claus. That might not be valid, according to the OpenSource definition, but unless you are planning to modify the code and provide it as SAAS I think this is no a problem.

  • I have been a vim user for more than 20 years. I tried to quit for a couple of years, but now I have just accepted my faith.

  • For Linux it is a huge difference. AMD and Intel have great open source drivers, while Nvidia have binary drivers with a lot of issues.

  • I'm free to choose any laptop I want for work. This means, that for me, the GPU and other processors are free. It turns out that I still avoid Nvidia like the plague. I don't care if it is free, if the drivers are horrible.

  • Rust @programming.dev

    Rust Analyzer Changelog #224

    rust-analyzer.github.io /thisweek/2024/03/11/changelog-224.html
  • Rust @programming.dev

    Rust Analyzer Changelog #223

    rust-analyzer.github.io /thisweek/2024/03/04/changelog-223.html
  • Rust @programming.dev

    A nice review of time, chrono and hifitime

    users.rust-lang.org /t/the-state-of-time-in-rust-leaps-and-bounds/107620
  • Programmer Humor @programming.dev

    Should I file a bug report? 😀

  • Rust @programming.dev

    Should I file a bug report? 😀

  • Rust @programming.dev

    Rustls Now Using AWS Libcrypto for Rust, Gains FIPS Support

    www.memorysafety.org /blog/rustls-with-aws-crypto-back-end-and-fips/
  • Rust @programming.dev

    This Week in Rust 536 · This Week in Rust

    this-week-in-rust.org /blog/2024/02/28/this-week-in-rust-536/
  • Rust @programming.dev

    Lessons learnt from building a distributed system in Rust

    www.codethink.co.uk /articles/2024/distributed_system_rust/
  • Rust @programming.dev

    Nice collection of AreWe*Yet , to track various aspects of Rust

    github.com /UgurcanAkkok/AreWeRustYet
  • Rust @programming.dev

    Asynchronous clean-up

    without.boats /blog/asynchronous-clean-up/
  • Rust @programming.dev

    Graphite internships: announcing participation in GSoC 2024.

    graphite.rs /blog/graphite-internships-announcing-participation-in-gsoc-2024/
  • Rust @programming.dev

    rustc_codegen_gcc: Progress Report #30

    blog.antoyo.xyz /rustc_codegen_gcc-progress-report-30
  • Rust @programming.dev

    : “Precious” files and core.precomposeUnicode support

    github.com /Byron/gitoxide/discussions/1304
  • Rust @programming.dev

    Rust participates in Google Summer of Code 2024 | Rust Blog

    blog.rust-lang.org /2024/02/21/Rust-participates-in-GSoC-2024.html
  • Rust @programming.dev

    This Week in Rust 535 · This Week in Rust

    this-week-in-rust.org /blog/2024/02/21/this-week-in-rust-535/
  • Rust @programming.dev

    arighi's blog: Writing a scheduler for Linux in Rust that runs in user-space

    arighi.blogspot.com /2024/02/writing-scheduler-for-linux-in-rust.html
  • Rust @programming.dev

    Rust Analyzer Changelog #221

    rust-analyzer.github.io /thisweek/2024/02/19/changelog-221.html
  • Rust @programming.dev

    The Linux Kernel Prepares For Rust 1.77 Upgrade

    www.phoronix.com /news/Linux-Kernel-To-Rust-1.77
  • Rust @programming.dev

    Building an Async Runtime with mio

    tweedegolf.nl /en/blog/114/building-an-async-runtime-with-mio
  • Rust @programming.dev

    This Week in Rust 534 · This Week in Rust

    this-week-in-rust.org /blog/2024/02/14/this-week-in-rust-534/