Dailymotion, Google Video, sevenload, german TV stations RTL and Pro7 even launched Clipfish and MyVideo respectively to compete with youtube. Youtube happens to be the only one that survived on Googles ad model, the others very quickly realized that paid premium content is much easier to handle (copyright, CSAM) and monetize.
While aviation is the origin of UX design, I'm uncertain whether modern cockpit design is born out of UX or out of a resistance to change. For example, for fuel-efficient takeoffs, you need to go in and override the ambient temperature and air pressure sensors and calculate what an efficient fuel mix would be yourself.
Whatever the reason may be, the fact that pilots regularly engage in rather complicated and obstruse workarounds shows that cockpit design shouldn't be taken as the holy grail of UX.
Incidentally, I also wonder if the many checklists pilots need to go through before the plane does anything are strictly necessary. It seems like automating these steps and removing associated buttons may be beneficial to reduce cognitive load and prevent operator error (such as happened with the Air India crash last year).
Most licenses, EULAs, contracts and so on don't have much precedent in court. There's no reason to believe that GPL would fold once subjected to sufficiently crafty lawyers.
Only if the code you copy pasted the LGPL part into is licenced under a compatible license, and Apache is not.
The simplest way to comply while keeping your incompatible license is to isolate the LGPL part into a dynamic library, there are other ways, but it is by far the most common.
copy/pasting, or using some other mechanism to do digital duplication is irrelevant - the removal of the existing license and essentially _re-license_ without authority is the problem, no matter what the mechanism of including the code is.
I mean, torrenting is decentralised and not technically takedownable. But it was entirely possible to make it legally painful for people involved in it, as seen in eg. The Pirate Bay, megaupload or an entire cease-and-desist letter industry around individual torrenting users
Intentional noncompliance with copyright law can get you quite a distance, but there's a lot of money involved, so if you ever catch the wrong kind of attention, usually by being too successful, you tend to get smacked.
> They just surveyed some college students and drew conclusions by running statistical analyses on the data until they got something that seemed significant.
Is this just cynicism or based on anything? From reading the methods section it doesn't appear this is what happened
> We used a mixed methods approach. First, qualitative data were collected through 41 exploratory, in-depth interviews (women: n=19, 46.3%; men: n=21, 51.2%; prefer not to disclose sex: n=11, 2.4%; mean age 22.51, SD 1.52 years) with university students who had experience playing Super Mario Bros. or Yoshi. Second, quantitative data were collected in a cross-sectional survey…
So interviews with a biased sample (students with experience playing the game) and then a survey.
Also, try adding up those n= numbers. They don’t sum to 41. The abstract can’t even get basic math or proofreading right.
If the body of the paper describes something different than the abstract, that’s another problem
EDIT: Yes, I know the n=11 was supposed to be an n=1. Having a glaring and easily caught error in the abstract is not a good signal for the quality of a paper. This is on the level of an undergraduate paper-writing exercise, not a scientific study as people are assuming.
Seems like n=11 should have been n=1. Use 19, 21, and 1 as a numerator of /41 and you end up with all the same percentages written in the abstract. A typo that should have been caught, but surely nothing more than that and certainly not substantive enough to qualify the claim below:
> This paper is very bad. The numbers in the abstract don’t even add up, which any reviewer should have caught.
> A typo that should have been caught, but surely nothing more than that and certainly not substantive enough to qualify the claim below:
Such an obvious error should have been caught by the authors proofreading their own work, to be honest. Any reviewer would also catch it when evaluating the quality of the sample size.
I find it strange that people are bending over backward to defend this paper and its obvious flaws and limitations.
It does seem to be cynicism, they're convinced the authors "gave people surveys with a lot of questions and then tried to find correlations in the data", but nothing indicates they did more than the 9 questions (plus one more for sex as a control) the paper includes, and restricted it to only Mario/Yoshi players. Ten questions is pretty short.
Do you not see the problem with drawing conclusions from a sample set that pre-selects for Mario/Yoshi players?
How do you think they’re determining that playing Mario/Yoshi prevents burnout if they only surveyed Mario/Yoshi players?
I really don’t understand all of the push to support this paper and disregard critiques as cynicism. The paper is not a serious study, or even a well written paper. Is it a contrarian reflex to deny any observations about a paper that don’t feel positive or agreeable enough?
I've critiqued it plenty in other comments, including that exact issue. However, that doesn't mean they "gave people surveys with a lot of questions" to p-hack, it seems like a study designed (albeit not well designed) to test one specific hypothesis. I see no reason to question that they did the methods as described in the paper, which were designed to test this very specific thing (they didn't even test "childlike wonder" in general, just self-reported Mario-induced childlike wonder), but their conclusions aren't supported by their data. If they were p-hacking as you accuse them of, why not have more questions? Why not survey non-Mario players too so there's a new variable to create significant results out of a null?
There is no server in Moscow, and I don't think there ever was. Muse Group left their original office in Kaliningrad for Cyprus pretty much the second the war started, and at this point has no offices or employees left in Russia. The servers always have been bog-standard cloud things, so Cloudflare, DigitalOcean, aws via Netlify and such.
Not good to hear they're based in Moscow, but that ship has presumably already sailed and sunk if you're running the auto-update code in an existing Audacity installation.
What other concerns besides national origin exist with this code? Nothing seems to qualify as a "back door," certainly.
Set the system language and timezone, the IP and originating ASN, to areas where APT28/APT29 is having active malware campaigns and see whether you'll receive a sample. Pretty simple.
The real question is whether they have changed their C2 behaviors since Valentine's day in 2023, and whether or not the AstraL1nvx botnet operator images are still available publicly.
After its inception, Tenacity unfortunately tackled an irrelevant, yet opinionated part of development first: The build system, together with any internal variables saying "audacity" getting replaced with "tenacity". As such, a lot of the work that's gone into it don't manifest to users, and merging any upstream changes takes needlessly long. As a result of this, Tenacity fell behind upstream a lot, being stuck somewhere around Audacity 3.1 while Audacity already was around 3.7. Last month, mercifully, Tenacity got rebased onto Audacity 3.7: https://codeberg.org/tenacityteam/tenacity/pulls/527 (a +261299 -395037 diff!)
As far as user-facing changes go, it's some new themes, a different compressor, keeping features visible which upstream has hidden by default, MKA support without FFmpeg, as well as support for some more niche systems (Haiku, BSD). All of this is in some stages of ongoing; Tenacity 1.4 alpha 1 got released a few weeks ago, and while that does include the rebase, it hasn't ported back all of the changes which were made before the rebase.
Noteworthy: Most of the development is being contributed by one person, Avery King.
As of right now, I'd recommend Audacity 3.7.x over Tenacity, as Audacity 3.x has been in maintenance mode pretty much since 3.6, while Tenacity is currently finding its footing again. Disabling update checking is easy enough anyway.
In the future though, it appears that Tenacity is going to keep alive legacy Audacity for legacy systems while Audacity 4 is on the way of adding more DAW features and dropping support for older systems. Definitely a worthwhile role to inherit.
The things that are happening to Audacity 4 have made me ponder doing the opposite: taking Ardour and stripping it down to make an audio file editor ...
A waveeditor inside a DAW is very helpful anyway; it's the place where you can chop up source files to become loops, and where you can throw in stretch markers to conform fluctuating tempo in the source to your beat. And once you have that going, there's very little in the way of having a template which only shows you that.
In Audacity, our goal is to keep it extremely approachable for beginners, so for us the idea of having one view of a clip in context of the project and a different view in which you only see the clip is something we'd rather not do. A wave editor window or panel separate from the main project timeline is however the industry standard, and as such it might be exactly the sort of feature which would be very at home in Ardour.
> A wave editor window or panel separate from the main project timeline is however the industry standard, and as such it might be exactly the sort of feature which would be very at home in Ardour.
Already landing in Ardour 9. However, at present, since our editing is always non-destructive, you can't do much there other than move start/end markers. We'll likely be doing more work on variable realtime time stretching in the march towards v10, and that will likely be accessible from both the main timeline and dedicated editors (but we'll see).
And yeah, Ardour's current goal is much more focused on being a powerful tool for people who do this stuff a lot, but there are a variety of arguments that support the idea that we need to do something/more to support beginners. We'll see about that too.
Hello! Indeed, I'm most the one pushing all this forward, and I keep planning to do this because I find it fun! I will take breaks occasionally, but I can assure anyone that I'll still be around. I have plenty of ideas regarding it too.
I do want to mention the build system part though: indeed, there are trade offs of Tenacity's build system vs Audacity's build system. However, on Windows (and hopefully Mac soon), it does allow us to ship newer versions of our dependencies, such as wxWidgets, which means we can do some neat little things. For example, the latest development nightly version of Tenacity (which you can download at https://tenacityaudio.org/nightly) supports Windows dark mode simply because wxWidgets now has support for it. Alas, it's an undocumented features on Windows that can break at any time, but for now, it works, and it's a nice little thing to have. It will especially help when we implement dynamic theming support (which I have figured out how to adapt to light/dark mode changes via wxWidgets). Of course, merging upstream changes can be very long, but we can also work around that. (Sometimes, we are the upstream too, especially with libmad and libid3tag ;). Either way, I find one benefit of it is allowing us to easily use newer dependencies that enable us to use newer features, and while this doesn't matter a whole lot on systems like Linux, *BSD, Haiku, etc., it does help with systems like Windows and (hopefully soon) macOS. (Currently, you can install Tenacity via MacPorts).
Also, I wouldn't necessarily say that work on the build system lead to us falling behind in development necessarily. I'd say that was due to the hiatus we had. Unfortunately, maintainer burnout can happen, and it doesn't help that Tenacity's start had a bit of its own controversy either with naming. At this point, that seems to be mostly behind us. From what I've seen anyways, I don't see many people mention it at all, but I could be wrong.
Regarding the rebase, yes, not everything's been ported back. In fact, for 1.4 alpha 1, I actually intentionally left out one thing: our own themes. I decided I was done dealing with the theme system, so I decided I would go about rewriting it. I had this planned for several years at this point, and there was already some code to experiment with before the rebase. If not for user themes, then it's certainly for the maintenance part of it, as themes should be easier to work with afterwards. (If anyone is interested in what the new theme system would have to offer, then I'd be glad to discuss it! :D)
Finally, would it be appropriate to say we're going to keep legacy Audacity alive "for legacy systems"? Maybe the "legacy Audacity" part, but not "legacy systems". If anything, I think it's safe to say that Tenacity on Linux requires a distribution like Debian 12 or later (including its derivatives). Sure, Debian 12 might be a bit older at this point, but I wouldn't necessary call it "legacy" just yet right now. Do we aim to support older distributions as time goes along? As long as it's reasonable. The same goes with Windows and macOS. In fact, Tenacity requires macOS 10.15 and has for some time. I want to increase the minimum version some time later, at least to macOS 11 if not later, but I'll likely give (what I think should be) plenty of time before that happens.
I think time will have to tell where this all goes. After all, I think there's some purpose for Tenacity to exist considering we've already had over 3,000 downloads for the 64-bit Windows installer for 1.4 alpha 1 alone. It might not be much compared to Audacity, and I think it pales in comparison to Audacity's popularity. To me, however, even 3,000 downloads is quite a lot, and it means something to me. There's also someone looking to package Tenacity for FreeBSD, albeit it appears to be the 1.4 alpha 1 version (which I would prefer the latest stable version for clear reasons). Yes, it's, like you said, a "more niche" system, but it's interest nonetheless.
P.S. I welcome any contributions from any contributors, especially those packaging Tenacity. We don't require any CLA, just the Developer Certificate of Origin (the same one the Linux kernel uses), and neither do we use AI to review contributions ;)
