F-Droid is in fact what an app store concerned about user safety looks like. Nobody gets hoodwinked into installing apps that track them or sell their data or otherwise abuse them on F-Droid.
F-Droid is so irrelevant that it doesn't even begin being targeted by supply chain and scam attacks. Being obscure always help with this, but pretending that it's the same threat model is absolutely false.
The XZ utils backdoor made it into Debian repositories undetected, although it was caught before it was in a stable version.
Debian repositories are quite secure, but also pretty limited in scope and extremely slow to update. In practice, basically everyone (I'm sure there are a few counterexamples) using a Linux distro uses it as a base and runs extra software from less tightly controlled sources: Docker hub, PyPI, npm, crates, Flathub etc. It's far easier for attackers to target those, but their openness also means there's a lot of useful stuff there that's not in Debian.
Holding up Debian as a model for security is one step up from the old joke about securing your computer by turning it off and unplugging it. It's true, but it's not really interesting.
XZ attack is an extremely rare event coming likely from a state actor, which actually proves that GNU/Linux is a very important target. It was also caught not least thanks to the open nature of the repository. Also, AFAIK it wasn't even a change in the repo itself.
In short, using FLOSS is the way to ensure security. Whenever you touch proprietary staff, be careful and use compartmentalization.
That article's premise is that the Android security model is something that I want. It really isn't.
The F-Droid model of having multiple repositories in one app is absolutely perfect because it gives me control (rather than the operating system) over what repositories I decide to add. There is no scenario in which I wish Android to question me on whether I want to install an app from a particular F-Droid repository.
Can you describe the threat model / specific attack under which... any of the supposed flaws on that page matter? (Most of the particular section you've linked appears to be about extra defenses that could be added, but which are unlikely to make a difference in the face of Android's TOFU signature verification on installed APKs.)
The section you linked in particular is a load of editorialized bullshit IMO. As far as I can tell the only legitimate complaint is that there is (or was?) some sort of issue with the signing methodology for both APKs and repository metadata. Specifically they were apparently very slow to replace deprecated methods that had known issues. However it's worth noting that they appear to have been following what were at one point standard practices.
The certificate pinning nonsense is particularly egregious. APT famously doesn't need TLS unless you're concerned about confidentiality. It's the same for any package manager that securely signs everything, and if there's ever a signing vulnerability then relying on TLS certainly might save you but seems extremely risky. On top of that the Android TOFU model means none of this matters in the slightest for already installed apps which is expected to be the case the vast majority of the time.
As far as I'm concerned F-Droid is the best currently available option. That said of course there are places it could improve.
I used WINE a lot in the 2000s, mostly for gaming. It was often pretty usable, but you often needed some hacky patches not suitable for inclusion in mainline. I played back then with Cedega and later CrossOver Games, but the games I played the most also had Mac ports so they had working OpenGL renderers.
My first memorable foray into Linux packaging was creating proper Ubuntu packages for builds of WINE that carried compatibility and performance patches for running Warcraft III and World of Warcraft.
Nowadays Proton is the distribution that includes such hacks where necessary, and there are lots of good options for managing per-game WINEPREFIXes including Wine itself. A lot of the UX around it has improved, and DirectX support has gotten really, really good.
But for me at least, WINE was genuinely useful as well as technically impressive even back then.
It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that.
I didn't know about the pending, official Rust frontend! That's very interesting.
Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow.
It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated.
Glad to hear a Rust rewrite is coming to Homebrew soon.
One of the reasons I switched to arch from debian based distros was precisely how much faster pacman was compared to APT -- system updates shouldn't take over half an hour when I have a (multi)gigabit connection and an SSD.
It was mostly precipitated by when containers came in and I was honestly shocked at how fast apk installs packages on alpine compared to my Ubuntu boxes (using apt)
pacman is faster simply because it does less things and it supports less use cases.
For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.
Less charitably, pacman is fast because it's wrong. The dependency resolver is wrong; it fails to find correct answers to dependency resolution problems even when correct answers are available.
* it’s purpose built for mega-sized monorepo models like Google (the same company that created it)
* it’s not at all beginner friendly, it’s complex mishmash of three separate constructs in their own right (build files, workspace setup, starlark), which makes it slow to ramp new engineers on.
* even simple projects require a ton of setup
* requires dedicated remote cache to be performant, which is also not trivial to configure
* requires deep bazel knowledge to troubleshoot through its verbose unclear error logs.
Because of all that, it’s extremely painful to use for anything small/medium in scale.
> dnf < 5 was still performing similarly to yum (and it was also implemented in python)
I'm perhaps not properly understanding your comment. If the algorithmic changes were responsible for the improved speed, why did the Python version of dnf perform similarly to yum?
Because dnf4 used the same dependency resolution as yum but they revamped it in dnf5 (it was initially supposed to be a whole new package manager with a different name)
> Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow
Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.
I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?
Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?
I would guess this change builds on the existing json endpoints for package metadata but that the Ruby DSL is remaining intact.
I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.
Is Ruby really the speed bottleneck in Homebrew? I would assume it would be due to file operations (and download operations), not choice of programming language.
Largely agree, though some things are notably difficult in some languages. Things like true concurrency for example didn’t come as naturally in Ruby because of the global interpreter lock. Of course there are third party libs, and workarounds though. Newer versions of Ruby bring it more natively, and as we’ve seen, Homebrew has adopted and makes use of that experimentally for a while, and the default relatively recently.
I can’t say that’s the only reason it’s slow of course. I’m on the “I don’t use it often enough for it to be a problem at all” side of the fence.
If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.
I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!
My hypothesis is that generally, there's no quality floor at which security departments are "allowed" to say "actually, none of the options on the market in this category are good enough; we're not going to use any of them". The norm is to reflexively accept extreme invasiveness and always say yes to adding more software to the pile. When these norms run deeply enough in a department, it's effectively institutionally incapable of avoiding shitty security software.
Fwiw w/r/t Trivy in particular,I don't think Trivy is bad software and I use it at work. We're unaffected by this breach because we use Nix to provide our code scanning tools and we write our own Actions workflows. Our Trivy version is pinned by Nix and periodically updated manually, so we've skipped these bad releases.
The question is what you're measuring. You can have a test that gives you whatever distribution of scores you like. But is the thing it measures competency in the subjects it tests, general intellectual ability, familiarity with the test format, etc.? The worst negative outcome is usually subordination of learning itself to preparing for the exam, which can happen even when the gatekeeping function of an exam still works perfectly.
All scientific research on this topic points to the conclusion that standardized test results are the single best predictor of subsequent academic performance. Some studies suggest that using GPA in addition to test results improves the prediction accuracy, but the marginal increase is very small, and it increases variance.
Everyone is well familiar with the downsides of standardized tests, but so far, nobody has proposed any alternative that better. Learning to the test is not great, but what’s the alternative? It’s not like anyone knows how to teach things that results in more actual knowledge and skills being attained despite lower test results.
> All scientific research on this topic points to the conclusion that standardized test results are the single best predictor of subsequent academic performance.
And academic performance is measured how? With standardized tests?
Obviously, yes. This is not circular: it is by no means tautological that people who did well on test X will do well on a completely different test Y that tests different knowledge and skills. The fact fact that it does gives strong evidence to the value of using these tests for admission.
It depends on what skills are necessary to succeed at test X and Y.
While the subject matter or details thereof might differ, it's possible that things like "knowing how to learn to the test (i.e. cramming)" or "reading between the lines of what the teacher/professor says is relevant" belongs to these skills. And these can absolutely be transferred between test X and Y.
So the question is, how much do these tests actually test skills in the subject matter and how much do they test "meta skills"?
The research shows that the tests are predictive almost precisely to the extent they test “meta skills”. We can even measure how much individual questions test meta skills vs specific skills. You can learn about this by searching for the terms “factor analysis” and “g-loading”.
The main problem I raised with the Gaokao isn't that it's biased, but that it has negative effects on the way education is conducted prior to university.
It's not difficult to find first-hand accounts of this; go browse social media posts by teachers in mainland China if you're curious.
There are similar problems of "teaching to the test" in other contexts, too.
I'm not categorically opposed to standardized testing and I never said I was.
Chinese education is also extremely constrained by the practice of "teaching to the test" to the point that the Gaokao indirectly stands in the way of innovation and reform in education. Schools doing interesting things to improve the quality of education are historically not very competitive on the Gaokao anyway (e.g., some unusual rural schools where students historically have bad prospects anyway and parents are overburdened or indifferent) or explicitly trying to carve something out outside the college track (e.g., private tech/entrepreneurship schools created by big tech companies).
There may be some good things about the Gaokao but having spoken to some (Chinese) teachers in China, it's also a limiting factor for education prior to university in a lot of ways, limiting the freedom of teachers and driving up risk aversion in parents.
(It's also effectively graded on a regional curve, which might be a good thing but isn't meritocratic in the straightforward way you suggest.)
There are those who argue that the entire high school curriculum in the USA is formed and molded by College Board changes to the SAT (and similarly to the ACT).
It makes sense, if the SAT starts asking you do calculate epicycles, schools are going to add Ptolemy to the study, or look worse than those that did.
Or (some) western education is too unconstrained and have strayed from purpose.
Scope of gaokao = teaching the test is just teaching everything a well rounded student should know. it's not sats where you can cram a few test tactic sessions and get a few 100 extra points. At the end of the day, gaokao is there to beat knowledge floor/foundation into kids, and one would argue knowledge floor is very deep if you want to generate most bodies that can transition into technical tertiary. Like... if one want human capita pool to be launchpad for innovation, you don't make calculus optional to athletics or other extra curricular.
IMO useful perspective is PRC diaspora, who readily acknowledges they don't want their kids going through gaokao not because it's ineffective but because it's tough, and half the reason they immigrate is because their statistically mediocre kids can't hack it under gaokao, but with some east asian education rigour/pressure will still be top 5% students under western education.
Are the Linux graphics drivers actually worse, though? I thought it was widely agreed that the open-source user-space drivers, e.g., in Mesa, are actually very good these days.
Idk how anyone could sustain the impression that pip was not broken unless they had basically never used anything else (including Linux package managers) long enough to have even a basic understanding of it.
And that's a big part of what's so frustrating about Python generally: it seems to be a language used by lots of people who've never used anything else and have an attitude like "why would I ever try anything else"?
Python has a culture where nominal values of user-friendliness, pragmatism, and simplicity often turn into plain old philistinism.
I had a breakthrough moment when someone at a workplace (software dev) said something about a thing that wasn't working on their device. Their language made it clear to me that they didn't know how to troubleshoot to figure out how to fix it. But they could write software that ran on millions of devices. Ok, that made me take a step back.
In the early 2000s I was in a rough patch in my career and wound up working at a small town web design shop that had done a lot of really amazing work, like a line of business system for car dealers, an e-commerce site for vineyards, a custom CRM for an academic department, etc. Nobody there knew about version control (not so weird in 2005) or how to write joins in SQL.
reply