I'm a security researcher - no quotes. I write detailed, highly technical write-ups for all of the issues I discover, including reproduction steps, root cause analysis and suggestions for fixes. I follow all responsible disclosure guidelines + any guidelines that the company or entity might have for security disclosures.
It's disheartening when you put this amount of effort into it, it gets silently patched, and you get no recognition or even a "thank you". But I don't let it bother me too much. I'm doing this research mostly for myself and because I find it interesting. The fact that I'm disclosing the issues is me being a good citizen, but I shouldn't expect a pat on the head for every issue I disclose.
Being ignored always sucks. But it's still infinitely better than doing all of the above and being threatened with a lawsuit (which has, unfortunately, happened as well).
Building the next update locally is slow because erofs has to compress the entirety of /usr on my rather old laptop and that takes a while.
Aside from that, I'm using flatpak for firefox and for some reason it takes absolutely forever (like > 15s) to start firefox on my machine, still need to look into why that happens.
Aside from those it's very usable. But of course it's running systemd from source so I'm not going to actually recommend anyone to run this who is not a systemd maintainer until we iron out the kinks.
I'm not sure if I miss IRC, or the simpler times that were when I was actively on IRC. Maybe it's a bit of both. But there's definitely some niceties in modern messaging applications that you can't get in IRC.
I was curious about the same thing, and found the following from Dave:
> I had to deal with that analogy a lot in high school, and I got used to it. It is, indeed, a rather popular food in schools. My problem with people using TAYT is that they end up misspelling it as Tate. Actually my name in the USA is usually pronounced "Tot", or better, T"ah"T, but while doing i18n testing in the mid-90s, and I discovered that the correct spelling (in Estonia) was with the ä. I gleefully adopted that, so I could break all of our protocols and web tools prior to the worldwide acceptance of UTF-8, and also because I was a death metal fan. Using the umlaut also makes it impossible for an automated spellchecker to respell it as "That", however no alternative has really worked. For a while there, the IRS thought I was three different people....
> The word, in Estonian, means "Star or planet", and as the Estonians did not know what an asteroid was, I have taken it to mean "Star or planet?".
While not saying anything about roots directly, I'm guessing it has to have been the reason behind him adopting the Estonian spelling of it. Maybe from grandparents or great-grantparents. Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
The word "täht" itself means "star" (both celestial one or a notable person) or "letter/glyph", not "planet".
> Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
Asteroids have been called "falling stars" in most languages for ages, nor would "asteroid" work well as a name. Nothing to do with anyone's knowledge of astronomy really.
I don't see how the two projects are related, so there shouldn't be any confusion. The project you linked isn't even called chibi, it's called chibi-scheme. If you suggest that we should not use common words in our project names if those words have been used before, we would've run out of names long ago.
Out of curiosity, what is the answer? From your comment, it seems like the more obvious choice is the incorrect one.
EDIT: By the more obvious one, I mean letting it cool and then adding milk. As the temperature difference between the coffee and the surrounding air is higher, the coffee cools down faster. Is this wrong?
That is the correct answer. Also there is a lot of potential nuance, like evaporation or when you take the milk out of the fridge or the specific temperatures of everything, but under realistic settings adding the milk late will get you the colder coffee.
Does the ceramic mug become a factor? As in adding milk first allows the milk to absorb heat that otherwise would have been stored in the mug too quickly and then radiate back into the liquid over time slowing its cooling curve. (I have no idea btw I just enjoy trying to come up with gotchas)
I'd say adding milk late is the best. You have coffee with volume and heat V and Q, milk v and q. Whatever you do, you'll get volume v+V and heat Q+q. Q can become Q' if you let it cool down first, or (Q+q)' if you add the milk first then let it cool down. But because milk is cold, the Q/V > (Q+q)/(V+v), hence the loss Q -> Q' is bigger than (Q+q) -> (Q+q)'.
The best answer though is to put the coffee on a plate, and forget about the milk.
Isn't the answer milk first, then let sit? You only have 2 minutes, so if you're adding the milk after 2 minutes have already elapsed, then you've already exceeded the time limit, meaning the final measurement would take place before the milk is even poured in.
The bigger the temp difference the more cooling. So by putting the milk in right away you make the temp difference between the surroundings and the coffee smaller = less cooling over your 2 mins.
> if it doesn't do what he wants him to do, it sucks
Well... yeah? The computer is a tool. If my tool doesn't do what I want it to do, or, by extension, it does things I didn't ask for or need, then it does suck. If my tool suddenly told me that my toolbox needs another, arbitrary tool Y that I don't need (in this case, TPM), then I will look for another brand.
The fact that "most users" are ignorant doesn't mean that the users who aren't ignorant should be punished. "Most users" are capable of doing the things you listed perfectly fine on other operating systems, like macOS or the various user-friendly Linux distributions, without being treated with hostility by the OS. The argument "it does the job" doesn't really hold water - the entire IT support industry is built on Windows not doing the job when the user doesn't know "why it works" as you put it.
> "Also, security, as we see every day, is all about backend infrastructure, like telcos not getting hax0red, amirite, and not about home users. After all, in my three decades of computing, 100% of harm to my "computing estate" came from companies being lax with their data in their "clouds", not from any movie-like hax0rology on my local systems."
Does the author not remember the days when connecting an unpatched Windows system to the internet got it hax0red in minutes? And how those hax0red Windows systems were a pain for the rest of us, being spam and DDoS sources and worse? And that Microsoft fixed it? And the author doesn't want to pay taxes for roads because they don't benefit from roads because they walk to the shops? Because they are a free thining independent Linux user who doesn't understand that the shop employees drive to work and the shop stock is driven to the shop.
I don't follow. They didn't fix it by installing ads in the start menu, making the command prompt take 4 second to load or constantly moving all the settings around. The fixed those things with security patches, which back then weren't even force bundled with packs of crappy features.
> Well... yeah? The computer is a tool. If my tool doesn't do what I want it to do, or, by extension, it does things I didn't ask for or need, then it does suck.
Exactly. We have strayed so far from the original path of the PC being owned by and serving its USER. Doing what the USER wants it to do. Running what the USER wants running. Upgrading when the USER wants to upgrade. I don't want my operating system to what Microsoft wants it to do, or what Apple wants it to do, or, to be fair, what Canonical wants it to do. I want it to do what I want it to do. The fact that this has become a weird "power user" point of view is scary.
I mean... yeah? If you do work using cars daily (delivery driver, cab driver, etc), you should know how to use one. Or am I misunderstanding what you're saying?
As a daily driver of a car, I don't need to know how it works. I know how to _use_ it - get in, turn it on, drive.
Who cares if it's electric or ICE, how combustion or regenerative breaking works, why you need to balance tires, how to change brake pads etc. I take it to the mechanic (IT Department) and they do magic, then give it back to me.
Same for computers. Why does the user need to know about USB 2 vs 3, memory, disk space, multi-threading, ad blockers, etc. Turn it on, use it, and send it out to be fixed when it doesn't work.
I bet that the maintenance costs on vehicles/computers is inversely proportional to their operators understanding of how they function.
If you hired a driver which would you rather hire, the one who knows which grinding sounds that a vehicle makes are good/bad or the one who just keeps using it with disregard for the grinding sounds because it isn't currently inhibiting their ability to drive?
You're abstracting the complexities down to a granularity that strawmans my contention.
If you cannot operate the vehicle you need to do your job you don't have that job. I'm not saying that people need to be experts. I'm saying if you cannot learn the tools needed to do your job then you shouldn't have the job.
> 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.
I'm a security researcher - no quotes. I write detailed, highly technical write-ups for all of the issues I discover, including reproduction steps, root cause analysis and suggestions for fixes. I follow all responsible disclosure guidelines + any guidelines that the company or entity might have for security disclosures.
It's disheartening when you put this amount of effort into it, it gets silently patched, and you get no recognition or even a "thank you". But I don't let it bother me too much. I'm doing this research mostly for myself and because I find it interesting. The fact that I'm disclosing the issues is me being a good citizen, but I shouldn't expect a pat on the head for every issue I disclose.
Being ignored always sucks. But it's still infinitely better than doing all of the above and being threatened with a lawsuit (which has, unfortunately, happened as well).
reply