As a New Englander, I am quite partial to "y'all" and "you all", mostly in written form. It is indeed a quite capable substitute to "you guys". But to my ear, "yall" is ever so slightly more informal than "you all", and so sometimes it doesn't feel exactly right.
$200 per month feels like a lot of a consumer subscription service (only thing I can think of in this range are some cable TV packages). Part of me wonders if this price is actually much more in line with actual costs (compared to the non-pro subscription)
Not only is in the the same range as cable TV packages, it's basically a cable TV play where they bundle lots of models/channels of questionable individual utility into one expensive basket allegedly greater than the sum of its parts to justify the exorbitant cost.
This anti-cable-cutting maneuver doesn't bode well for any hopes of future models maintaining same level of improvements (otherwise they'd make GPT 5 and 6 more expensive). Pivoting to AIaaS packages is definitely a pre-emptive strike against commodification, and a harbinger of plateauing model improvements.
In my experience Java debuggers are exceptionally powerful, much more so than what I've seen from C/C++/Rust debuggers.
If I'm debugging some complicated TomEE application that might take 2 minutes to start up, then I'm absolutely reaching to an IntelliJ debugger as one of my first tools.
If I'm debugging some small command line application in Rust that will take 100ms to exhibit the failure mode, there's a very good chance that adding a println debug statement is what I'll try first
Sure. It’s got breakpoints, and conditional breakpoints, using the same engine as IntelliJ. It’s got evaluate, it’s got expression and count conditionals, it’s got rewind. It has the standard locals view.
Rust support has improved in 2024 pretty strongly (before this year it just shelled out to lldb); the expr parser and more importantly the variable viewer are greatly improved since January.
It can do any single expression, and the results are better than lldb, but it can’t do multiple statements and not everything in Rust can be one expression; you can’t use {} here
Hmm, I've only seen that in some 'new-ish' languages sometimes (like currently Zig), which I think is a compiler bug when generating debug info. In C/C++ I see such random stepping only when trying to debug an optimized program.
Open sourcing is always good, because maybe you can learn some things by reading it. Also, Winamp Legacy is a fairly important piece of software, so having an archive of its source is a great thing.
But the restrictions on the source are interesting. To quote the license file:
* No Distribution of Modified Versions: You may not distribute modified versions of the software, whether in source or binary form.
* No Forking: You may not create, maintain, or distribute a forked version of the software.
* Official Distribution: Only the maintainers of the official repository are allowed to distribute the software and its modifications.
I'm guessing the "No Forking" clause means I can't release my own media player based on this source code, but the language is curious because they explicitly welcome contributions and for a project hosted on Github the standard way to do that is to "fork" the project into your own account.
> By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
There are two distinct meanings of fork and you are conflating them I think. I suspect winamp's license is using the sense of the (pre GitHub) idea of creating a distinct version of a project maintained by a different group, and the GitHub ToS specifically refers to forking within the GitHub platform.
Let's say you are hallucinating "two distinct meanings of fork". Unless you are referring to tableware, a fork is a fork, it's any distribution of a software, based on the software in question. The fact that most forks on GitHub serve only operational purpose, nobody actively maintains them and nobody normally uses them instead of the parent project, doesn't change what they are: a distributions for (potentially, and unless PR is accepted, actually) distinct software projects, based on a project they are forked from. You are just so used to the button and the process, you lost track of what the label on that button actually means, why it's called "a fork". And the answer is, well, because it's a fork. In no way it is different from starting a MariaDB project. As soon as you press that button, you are distributing your own software, based on that parent software. If the parent project disappears, or moves on, or never accepts your PR, which somebody really likes, other people can (and probably will) use your fork in a way that isn't any different than, well, any larger and "more obvious" fork.
So, essentially, winamp license means nothing. They already forfeited their right to deny you forking by posting it on GitHub.
Just an aside, but really hope "maybe you're hallucinating..." doesn't catch on in human to human speech.. Its great for the models, kinda too flattening for real discourse.
“…maybe you’re hallucinating…” and “…I must be hallucinating…”
Have been part of human to human communication since the 60s, when people in fact could very seriously have been. It continued on for acid flashbacks and other surreal moments
"Maybe you're hallucinating", let alone "let's say you're hallucinating", is a really weird take on someone thinking of a reasonable semantic distinction even if you disagree about its existence or relevance.
Perhaps you can say that to a friend as banter or in a tongue-in-cheek way, similarly to how you might say "I must be hallucinating" about yourself. But as an argument in a discussion with a stranger, it seems rather dismissive and inappropriate.
And it does reek a bit like something stolen from LLM terminology.
Thats certainly true, and at least in philosophy similar discourses go back much farther than that!
But the senses are importantly different right? In the former, we are talking about clearly psychological assertions, in the form of skepticism, within an otherwise shared world.
Here it is clearly rhetorical though, right? Talking to GP as if they were LLM. Using it for a not-so-shorthand for "I believe you to be wrong about this".
Its really not a big deal. It's just interesting, I guess, how much the tools tend to master us and change us while we lie to ourselves that its the other way around.
Also, hadn't heard "acid flashbacks" in a long time.. Still waiting for mine!
I've used LSD a few times, but to my knowledge never had any "acid flashbacks". Maybe that's for the best... but seems like it might be fun if one was in a safe environment.
Anything the owners of the Winamp code can find in order to take legal action on will be distributed. Rule 2 (and 3) is always superfluous in practice.
They don't give permission, so the lack of definition doesn't really matter.
If they were trying to grant a narrow permission and then enjoin someone they thought was outside of their definition, it would matter (But they just aren't giving permission to distribute modified versions).
You can, but only private forks of a private repo are allowed. Private forks of public repos are not allowed by design (modulo some weird bugs that were discussed on a past post).
A fork is a copy of a repo at a certain version. A copy of the files of the repo without the .git folder is effectively a fork. Either way, their terms contradict what GitHub allows.
When you click "fork this repo" in GitHub, that clones the repository, and re-publishes it under your username.
When you clone a repo to your system privately, that does not involve publishing. If this is their intended meaning of "fork", then this license must explicitly disallow cloning the repo!
The older, still in use today meaning is what happened when Oracle bought MySQL and ruined it. People forked it and now we have MariaDB. Basically, it means a fork in the code base and now there are two separate projects.
Until Github came along, "Creating a copy of software for your own personal use" had never been widely-accepted definition of the word "fork" in the context of software development. Forking a project has always involved independent publication and maintenance of said project.
The typical way of copying a project for your own personal use on GitHub involves publishing that copy on GitHub. So, it is a real fork—maybe not a well maintained one, or one that the author is particularly excited about, though!
When you fork a project on GitHub, that literally creates a parallel working history, and publishes it under your username. That's what GitHub means by "fork".
OK, but a mirror only exists to share an exact (hopefully up-to-date) copy of the repo. So we are just moving the goalpost from the moment you create the fork to the moment you edit it. Did that really change anything? I don't think so.
You can Zeno's-paradox-away the distinction between a bathtub and a kitchen sink, but that doesn't make them the same thing.
This sort of argument change how people understand words, and it also doesn't change how lawyers interpret laws nearly as often as people think. It's still fun, though!
In particular I think you may press the fork button on the github repo as per github rules. However, you are not allowed to make any commits to this new repo.
Interesting to see how would this play out in case of a lawsuit against an user who doesn't honor their license because it clashes with GH one.
Anyway, that code has already been swallowed by some AI that will reorganize it, split in functional blocks and regurgitate it elsewhere someday, so too late for them to complain.
The GitHub ToS is not a software license. It is the terms for using the GitHub service. The penalty for breaking it is that your GitHub services might be terminated, not that they can somehow relicense your software.
This part of the ToS explicitly does grant such a license to other GitHub users.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).
I was thinking that. The language seems not quite clear, at least to a non-lawyer like me:
> you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)
So, on GitHub, we can "use", "perform", and "reproduce". Does editing/modifying fall under any of those verbs?
Cloning is part of GitHub's functionality, so therefore we can clone it but can only commit those changes back to GH. We are permitted to do anything that is part of GH's functionality.
There is no conflict here. The quote from Github's ToS means you allow others to copy the source code you've made public, it cannot and does not give you any rights regarding what you do with the code beyond that. Points one and two of the Winamp license quote are essentially one and the same, just worded in a different way for clarity.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
It would be weird to have a license that lets me create a fork in my own repo, but doesn't permit me to distribute it. If I create a fork of a public repo on GH, I require a license to distribute it because a public repo can be forked or downloaded by anyone. I can't them doing doing it. Therefore permission to further distribute is required for participation on GH.
Because if I didn't have a license then that would mean I would be liable for infringement every time someone downloaded it from GH. That's exactly why GH has the TOS that it has - so that nobody can be sued for just using GH when a rights holder uploads their own work to a public GH repo.
There is only 1 license, and it is issued by the WinAmp copyright holders. No additional license is created by hosting a repository on GitHub. The only (extremely theoretical) issue would be between GitHub and the WinAmp folks, if GH believed that WinAmp is violating its TOS.
I guess they mean with "fork" a rebranded or self-compiled version. So unmodified source code, but different logo or name. Or compiled with different settings or for an unsupported platform. Something along that line. But calling this fork, after they are already forbidding modifications in point 1 is really strange phrasing.
It feels like they wanted to make sure that no one distributes a modified "Winamp" that isn't built from the official sources, which makes sense, but they went too restrictive on it. The usual way to go about it is to say "if you want to maintain and distribute your own fork of this product, you must change the name and the logo to make sure it doesn't infringe on our branding". Telegram does this for its client apps, for example.
I bet that they would disagree with you. This is an "all rights reserved" "source available" license. Given the redistribution restrictions, their assertion that it is a "copyleft" license is clearly false.
This is like a park having a sign on the corner telling you to not step on the grass because it is privately owned but people go and make picnic there anyway
> but the language is curious because they explicitly welcome contributions and for a project hosted on Github the standard way to do that is to "fork" the project into your own account.
It's because techies instead of lawyers wrote it. The first and second restrictions overlap anyway, as it says you can't distribute a modified version in the first restriction, but then can't distribute a forked version in the second restriction. I'm not sure what the difference is, and courts don't like redundancy and will often invent reasons to interpret the phrases as meaning something different.
I got a $15 parking ticket recently and got it dismissed after I contested the ticket on the basis that the way the city regs were written, they used both "parking spot" and "parking area" and thus "parking area" cannot be synonymous with "parking spot," which altered the meaning of the reg they used to ticket me.
It's not open source. however I like it. I wish closed source licenses were more of a thing. as it is, our software tends to fall under two two extremes very liberal open source. closed build artifact only. with very little in the middle.
I think a "here is the copyrighted(with all that implies) source for you to compile on your machine" software distribution would be a great middle ground. but it is a thing you normally only see on large screwball enterprise contracts. because the normal practice of here is the compiled build artifact really sucks when trying to trouble shoot why it is not working on your machine.
I'm not sure forking the repo would create a forked version of the 'software' if the fork's sole purpose is to develop a pull request. But I guess it's somewhat ambiguous langauge, and better safe then sorry when it comes to lawyers (which I'm not).
Presumably the prohibition is around creating a forked release, with the language being intentionally a bit vague to cover their bases. Unfortunate that that's how these things are, though.
Interestingly the first line says, even distributing a modified version in source form is not allowed... so a GitHub fork with a tiny modification already violates this line.
In a very specific technical sense, it could be argued that it doesn't — the data for GitHub forks (i.e. their branches and the commits of such) is actually stored within the base repo forked from.
In other words, by forking something on Github, you're not distributing anything; rather, the original org is now distributing an additional thing you made — your fork branch[es].
This is the source of many confusing things about the security of GH forks; and the source of some recent GH vulnerabilities.
Also, if you're curious, this isn't a meaningless "implementation-level distinction", as it has semantic implications for repo management: it means that the branch attached to a PR coming from a fork repo continues to exist in the base repo, even if the fork repo that that branch originated from gets deleted. Because that branch was always "in" the base repo to begin with; the PR just changed the branch's GH ACLs to make it accessible to the owners of the base repo.
(Really, the "fork repo" itself is an illusion — it's like a SQL view. There's only the base repo, which contains both regular branches, and user-fork-namespaced branches. This is in part why forks can't be private; they're just a view of resources in another repo, already security-controlled by that other repo; so they can't have their own additional security logic acting on those same resources!)
This implementation choice has always felt a bit odd to me, almost like premature optimization. Is there a reason to have done it this way other than storage deduplication? Since git is already a content-addressed store anyway, how hard would it have been to have some kind of abstraction below the repo layer that would provide the same deduplication?
At this point there's obviously huge inertia in Github's early architectural decisions, but if you were building Github today, would it still make sense to go this route?
GitHub's fork feature works outside of git itself. It does not utilize the .git directory, and therefore does not utilize git's deduplication.
EDIT: Oh, I see what you mean. It would definitely be interesting to solve this namespace conflict problem from inside git. I wonder how many times meta-branches (or something similar) have been advocated for.
I agree; your interpretation is reasonable and plausible. But it's disappointing to have this ambiguously, since the license file has a whole section for "Definitions" and yet it fails to define what "forking" means in this context.
Yeah the license self-refers as "copyleft" (an unregulated term afaik), and they have been very careful to avoid usage of the term "open source" rather preferring to say things like "the source is open".
Regulated or not the use of "copyleft" still seems deliberately misleading to me - I don't think the restrictions you've listed are in line with the intent of the copyleft movement.
While "copyleft" is just a word like any other word, and subject to the same descriptivist drift as any other, in this case it is a specific word coined by a specific org, with a pretty specific definition. One that this license does not meet.
Frankly, copyleft is MORE permissive than generic bullshit weasely term "open source" (thanks to corp-friendly ESR). The fact they try to avoid using "open source" but willingly use the more "free as in freedom" word "copyleft" is a bit distressing.
I'm tired of this whole "shared source" movement, it's disingenuous, and ruins the spirit of actual open source (let alone "copyleft").
Boo on Winamp. Shame. I'm still using 5.666 until I die. I won't use their newer stuff, because it's clear they're not doing it with love but just trying to find another captive market of nostalgia nerds.
Copyleft just means you lose license privileges and revert to unlicensed copyright rules when violating its terms. There's no reason you can't use that principle in a more restrictive way than GPL.
That's the FSFs spin. Ultimately GPL is a promise not to pursue an entity for copyright violation without the need for a signed contract. That promise is revoked when you disobey the copyleft.
While I did make the point that "copyleft" is not a protected term & therefore can have many definitions, I've never heard your definition & it's certainly not the widely accepted one.
The language is pretty clear to me. I understand what you’re saying, and suspect that this is an honest oversight on their part, but as it currently reads forks are prohibited.
They may have meant something else, but what it says now is “no forking.”
They know exactly what they're doing. They're open-washing the program to get attention. It worked. As I write this, it's the number one YComb story. But, it's in no way, shape, or form open source.
I am all for reverse Hanlon[0]: don't assume incompetence when people profit from something. I think however that "source available" is a legit business model, and not just a HN hack. They made their source code available after all. Although it isn't compatible with github, as the others pointed it out.
I think this is a great license as it allows you to download the code, make modifications, create "pull requests", etc, but you are not allowed to compete, or distribute it with a virus baked in. That way the maintainers have full control and don't have to worry about hostile takeovers, or people making profits without contributing.
Well, it's at least slightly more open than e.g. Microsoft's source-available repositories, let alone leaked proprietary source; as you do have the freedom to e.g. read the Winamp source code and then ground-up reimplement a Winamp-alike program, without their lawyers coming after you. (Orgs like ReactOS don't let people contribute if they've ever read code from a Microsoft source-available repos, lest ideas inspired by that code end up in the ReactOS codebase, and Microsoft sue them for that.)
I'm not sure what to call a codebase that only grants you the (implicit) right to not be sued for reading the source and then getting inspired by it, though.
I thought reading closed-source code is a very bad idea, as if you wind up writing something similar, then you're possibly guilty of copyright infringement. If you have one team look at the design, catalog the features, and describe how it works in detail, then you can have another team implement it, and you're on legally much better ground (unless patents):
> I thought reading closed-source code is a very bad idea, as if you wind up writing something similar, then you're possibly guilty of copyright infringement.
The idea is to avoid accidentally copying code, though TBH i think this is some sort of legend that comes from decades ago and not really practical (nor, as the article mentions, required by law). Writing something similar alone won't make you guilty of anything, otherwise people who worked as programmers wouldn't be able to work at a different company on the same or similar field again ever.
How is it zealous to prevent people from co-opting and diluting the meaning, like you have done here? If anything, companies are trying to misuse "open source" for their source-available code.
This license prohibits maintenance. If the official copy had a single bit that prevents it from compiling on your local machine, you cannot make that change. Only the "maintainers of the official repository" are permitted to do that.
I'm assuming that the tokens used to encode an image are entirely distinct from the tokens used to encode text. Does anyone know if this is actually the case?
I would assume it has a "mode" token where it switches between text/image (and now audio), or you'd have to try to maximize the number of reserved tokens between multiple modes. GPT-4o did go from 100K to 200K vocabulary, but as far as I understand all of that vocabulary is in use for text (reducing the token cost for non-English).
It's not clear to me that trying to assign semver semantics to a command line interface is going to work well; trying to define the "interface" for command line tools seems too challenging. Perhaps one might suggest that caddy should have used a different versioning pattern, but I have to admit that the x.y.z pattern is so prevalent these days, I have a hard time faulting someone for using it.
Yes. “Superalignment” (admittedly a corny term) refers to the specific case of aligning AI systems that are more intelligent than human beings. Alignment is an umbrella term which can also refer to basic work like fine-tuning an LLM to follow instructions.
Is this not something of an oxymoron? If there exists an ai that is more intelligent than humans, how could we mere mortals hope to control it? If we hinder it so that it cannot act in ways that harm humans, can we really be said to have created superintelligence?
It seems to me that the only way to achieve superalignment is to not create superintelligence, if that is even within our control.
Not self-evident. Fungus can control ant. Toxoplasma gondii can control human. Who is more intelligent? So if control of more intelligent being is possible, could it be symbiotic to permit? Alpha-proteobacteria sister to ancestor proto-mitochondria and now we live aligned. But those beings lacked conscious agency. We have more than them. Not self-evident we will fail at this.
Another example is the alignment between our hindbrain, limbic system and neocortex. Neocortex is smarter but is usually controlled by lower level processes…
Note that misalignment between these systems is very common.
Alignment was the original term, but has been largely coopted to mean a vaguely similar looking concept of public safety around the capabilities of current models.
A quick off-the-cuff remark based solely on the title: in 2024, I think the state of the terminal has never been better, in large part to Microsoft making a high quality terminal easily available to everyone on Windows [1]
As an application author, I love being able to assume that all major platforms have a good terminal and that my favorite terminal rendering libraries should Just Work on all of them
I mainly use microsoft terminal now just beacuse it did a better job handling more of the font decorations (italic was one that I recall). My one gripe though is that it seems like microsoft terminal is still kind of slow at scrolling. If I accidentally grep for something that spews a lot to the screen, terminal is just plain hung up a bit. And for many of us - but not everyone? - control-space in emacs is just kind of broken. Long standing open issue for that one.
I really dislike that they re-used the TERM value from xterm instead of getting their own merged into terminfo. And then not documenting which sequences are actually supported and which aren't.
You're getting downvoted but you're not wrong. Using TERM=xterm-* should be deprecated, and in this case in particular that likely means stepping on some toes.
It's like the user agent string in browsers. Using that instead of checking for feature availability directly is always going to end up in a mess like this over time. Heck, there wasn't a Windows 9 because of how much software would break because they had `if (osversion.startswith("9"))` check to decide if it needs to act in pre-XP mode, long after XP itself was EOL. Most people aren't willing to give up functional workflows on principle alone. "stepping on some toes" massively understates the impact.
Surely you can imagine that it takes years or more to get people to update though, so switching to a new entry right away could make for a bad user experience.
True, but no matter the terminal, you still have to deal with either cmd or PowerShell (and its horrendous startup time), "active code pages", and the fact that you cannot write UTF-8 to stdout without it getting messy - you need WriteConsoleW and/or SetConsoleOutputCP but that affects the whole environment, ... cli on Windows was and is painful.
Once upon a time, I was tasked to rewrite build scripts for windows based team from .bat files to bash scripts (via a git-bash). People on that team were not exactly unix fans, in fact they resisted hard almost everything coming from us linux weirdos. But reduction in build time was so big they asked for this and embraced it with genuine love.
Does this mean I can run the Build Your Own Text Editor[0] tutorial in Windows without WSL? I did it in Linux a few years ago, recently heard of Crossterm[1] and was thinking trying to remake it with that, but maybe it's not necessary?
Yes, although thankfully on Windows we have a modern graphical terminal, with a scripting language that took plenty of learnings from non-UNIX CLIs into account.
https://en.wikipedia.org/wiki/Tomography: `The word tomography is derived from Ancient Greek τόμος tomos, "slice, section" and γράφω graphō, "to write" or, in this context as well, "to describe."`
The sample is stained (to make thigns visible), then embedded in a resin, then cut with a very sharp diamond knife and the slices are captured by the tape reel.
reply