Yeah, I agree. While this is a terrible move IMHO, from my superficial reading of the GPLv2 it doesn't really constitute a violation: the license imposes that the source be distributed to anyone who asks, potentially even charge a fee to cover its distribution costs, but it doesn't require that development happen in the open.
GPL not defining a time limit to comply also doesn't mean there isn't a reasonable limit on compliance time. Google is more than capable of quickly complying. It comes down to whether a judge would think what they're doing is reasonable and we don't think they would.
The software also isn't in the preferred form for modification. The build system which runs Git commands and doesn't work as intended without it. You have to make a Git repository for it to work and there's meant to be a separate one for each separate component. It spews out errors.
I mean, the only way to test this is to require of Google here to release the source code. And then look at how a court will evaluate it. For instance, what if Google never sends the source code? What if they claim that no request made it in? Though I guess this can be ensured, e. g. via letter that is registered being sent and then looking at Google's response to it.
So right now I think we all probably do not know. Google MIGHT refuse to release the source code, but it could release it - we don't know yet. Someone has to test that.
> For instance, what if Google never sends the source code? What if they claim that no request made it in?
That would be a violation of the license terms. All Google has done so far is, apparently, to make it hella annoying to access the source code (but not impossible).
I feel like one of the takeaways here is that Rust protects your code as long as what your code is doing stays predictably in-process. Touching the filesystem is always ripe with runtime failures that your programming language just can't protect you from. (Or maybe it also suggests the `std::fs` API needs to be reworked to make some of these occurrences, if not impossible, at least harder.)
On a separate note: I have a private "coretools" reimplementation in Zig (not aiming to replace anything, just for fun), and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. However, cross-checking uutils I noticed it does have a bunch of unsafe blocks that call into libc, e.g. https://github.com/uutils/coreutils/blob/77302dbc87bcc7caf87.... Thankfully they're pretty minimal, but every such block can reduce the safety provided by a Rust rewrite.
> and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see.
Probably will depend on what platform(s) you're targeting and/or your appetite for dealing with breakage. You can avoid libc on Linux due to its stable syscall interface, but that's not necessarily an option on other platforms. macOS, for instance, can and does break syscall compatibility and requires you to go through libSystem instead. Go got bit by this [0]. I want to say something similar applies to Windows as well.
This Unix StackExchange answer [1] says that quite a few other kernels don't promise syscall compatibility either, though you might be able to somewhat get away with it in practice for some of them.
Since it's a personal project, Linux compatibility is the only thing I care about right now. I'm testing it under WINE as well, just because I can, but I don't have access to Mac OS so I'm skipping that problem entirely for now
I noticed the performance issues too. I started using Jan recently and tried running the same model via llama.cpp vs local ollama, and the llama.cpp one was noticeably faster.
Thank you. I also found it exhausting to read so many short sentences that just assert little pieces of information without saying anything of substance.
In my university, probably because the CS department at the time was an underfunded offshoot of the faculty of Mathematics, we basically didn't have access to computers (and I didn't have a laptop of my own).
We did almost everything on paper, even exams. I admit writing MIPS assembly on paper seemed strange to me at the time, but the effort you put in to put things black on white somehow made the knowledge stick into my mind more effectively. Some of that knowledge will stay with me forever, and I'm not sure the same could be said if I had taken "shortcuts".
I used to write code in a spiral notebook when I didn't have access to a computer. It was also hard to code on a computer in those days when the output device was an ASR-33, or a screen was 24x80.
This article has a weird tone. It directly criticizes the results of this AI-driven coding effort (which the author admits is of bad quality), while at the same time it tries to reassure the reader that they're not here to criticize the author of the PR.
not if they are different authors; AI wrote the code and the human the PR. These used to implicitly be the same person but this is something important we have lost. You've now got a smart, former developer in a position of power vouching for code they essentially didn't write.
So you're saying that the slop thus produced is not the responsibility of the human authoring the PR? I would assume it is, regardless of how it was produced.
It's not like the Shopify CEO intentionally tried to make something low quality. Was he out of his depth? Sure, but I don't fault him for trying. I think the people hyping up this event have caused more harm than the event itself.
Helix is my default, as it's a more mature/stable editor. I fire up Flow Control from time to time to follow how it's developing and for more casual editing. They both do an excellent job overall, but my muscle memory binds me to Helix for now.
(I know Flow Control provides Helix keybindings, but I haven't tried that yet and I generally like to retain the default behavior of an editor so that my user experience is more "portable" across machines.)
