I’m aware that the things I’m about to discuss aren’t very important; mostly I
just want to organize my thoughts, and perhaps vent a little. If you want to
read something that I consider very important, go read
With all that said, here are some nice fancy pullquotes:
Overbite Chrome is no longer supported due to Google’s extension format
changes. It is no longer compatible with Chrome 24 and up… For now, use the
Public Gopher Proxy (below).
As a consumer, yes, you have lots of choices in which Linux you use.
This does not mean Linux is in any sense _about_ choice, any more than
because there are so many kinds of cars you can buy that cars are about
We will not be proceeding with this feature request. We recognize that there
is a significant number of you who will be disappointed with this decision,
evidenced in part by the many stars on this issue. We debated it
extensively, both inside the team and with members of the community. In the
end we decided that the WontFix resolution was more in keeping with Chrome’s
core value of simplicity
— miket, representing Google in a chromium bug about restoring side tabs
(In reply to Miguel Hernandez from comment #108)
Just dropping ALSA support out of the blue doesn’t fix anything, Gian-Carlo,
and it can be added back for now with absolutely no overhead.
Installing Pulse Audio fixes all the known issues with the ALSA backend.
— Anthony Jones, representing Mozilla in a bug about firefox being broken on all ALSA systems
By most accounts, somewhere between the majority and the vast majority of
Python code targets Python 2. Some even claim that all of Python 3.x put
together is about as popular as Python 2.6, the outdated version of
Python 2. At least personally, almost all of the python I’ve ever written
personally or professionally uses Python 2.7 or earlier.
and finally, to balance all that out, surprisingly detailed documentation
about the rationale for and how to cope with (with eyes to both forward and
backward compatibility) the changes brought about in
I guess the real question I want to ask then must be: What is the role of the
user in shaping the software they use?
For what I’d call “personal” projects, which exist to solve a workflow that
the author encountered, I think the question itself suggests an answer. Since
the author is the primary user, anything useful to them goes in, as does
anything else that they may not use but are comfortable supporting. Since it
is a “labor of love”, feedback from users technical and non- alike has an
advisory role. There is an important distinction, though: technical users can
implement these features, and, if they are rejected, go fork off their own
project. If the original project is being truly unreasonable about code
inclusion, this fork can even become the new authoritative version. But this
doesn’t happen very often.
Some projects, whether intentionally (e.g., LLVM) or by accident (e.g., Linux)
will grow beyond this scope (in those cases, vastly so). The question then
becomes murkier. The two projects I’ve chosen for example here are both, I
would say, “fork-proof” – LLVM has a very lenient code acceptance policy (see:
all of the ghc-specific portions of the backend), while Linux has an extremely
powerful module interface against which things can be built that do not merit
inclusion into mainline. A user could fork LLVM, or Linux, but their
version is extremely unlikely to become authoritative. Even if one does
become authoritative, or close to it, that decision may also revert if the new
fork does not live up to the quality standards of the old (I’m thinking about
Needing to preserve existing quality standards is compounded by these projects
having enormous codebases. And this, in my estimation, is the heart of the
problem. To pick new examples: I, someone technical and already knowledgeable
about systems programming, could in fact fork firefox or chromium and add in
new features (as upstream would put it; I would probably call it fixing what
is broken). Upstream does not want these changes, as alluded to in the above
quotes. So I would have to maintain my own changesets on top of master, in
perpetuity. I could probably even do this: I’m a maintainer, I’ve carried
(sometimes quite extensive) distro-specific patches before on large codebases.
But my version will clearly never become authoratative, for a variety of
reasons, and the time commitment will become quite large.
In the case that prompted this post, I’m upset because neither major browser
will adequately perform the tasks I need them to due to removal of existing,
working code. (And again, I’m not without perspective here; I understand that
there are much bigger problems in the world, even in the open source
ecosystem, that more urgently require attention.) Most users will not have
this problem: ALSA-only users will migrate to chromium, and treestyletabs
users will stay on firefox, and the intersection between the two groups will
There is little more immediately frustrating to users than breaking their
existing setups, and so I want to relate this back to systemd. There’s a lot
to like about systemd as an init system (and anyone who says otherwise is
exaggerating due to being upset for the reasons described above), and
personally I’m glad someone has decided to care about the udev code even if I
don’t agree with how. And none of that should affect me at all, except that
it must: large, important projects forced systemd-only (much like firefox is
doing with Lennart Poettering’s other project right now…). And while
and people more upset than me are trying to fork Debian (link intentionally
missing) without it, the reality is that when Debian decides that maintainers
don’t have to take patches to add SysV initscripts, there isn’t anything I can
do about it.