HN user
If I read an inflammatory and disturbingly arrogant comment, in which personal opinions are presented as facts, and contrarianism is practiced as an artform, there's a near 100% chance tptacek wrote it.
You seem to need it more. Let me help: "n. an adherent of fascism or similar right-wing authoritarian".
Sounds about right.
Mussolini said: "Fascism, sitting on the right, could also have sat on the mountain of the center ... These words in any case do not have a fixed and unchanged meaning: they do have a variable subject to location, time and spirit. We don't give a damn about these empty terminologies and we despise those who are terrorized by these words"
Quoting Robert Paxton's "The Anatomy of Fascism": facism is "... a form of political behavior marked by obsessive preoccupation with community decline, humiliation, or victimhood and by compensatory cults of unity, energy, and purity, in which a mass-based party of committed nationalist militants, working in uneasy but effective collaboration with traditional elites, abandons democratic liberties and pursues with redemptive violence and without ethical or legal restraints goals of internal cleansing and external expansion."
McCarthy was obsessed with "The Red Menace", and was willing to abandon just about any ethical or legal constraint to both cleanse the United States, and to spread his idea of Americanism.
He enlisted industry, traditional elites, and whatever political support he could find his obsessive pursuit of cleansing the US of communism (and homosexuality).
What's especially scary is that you write off his wholesale destruction of careers and lives as an ethically justified approach to the problems of the Cold War (and his problems with homosexuality), despite the tactics baring a striking similarity to the CCCP's enforcement of party politics through social, commercial, and direct governmental intimidation.
We're lucky that McCarthy was never truly unleashed on the Red Menace; your implied support of him and his tactics is abhorrent.
The EU (and Germany in particular) have data protection laws ... so, yeah: I fear the NSA the most.
The 'back door' system support isn't as complicated as you make it out to be. Centralized administrative access to user data must exist for support, maintenance, and legal purposes, and it will be implemented throughout the organization without anyone batting an eye.
In addition, internal analytics systems will have reason to tap into data streams/events, as will content-based advertising systems.
All of these things are often designed to provide general interfaces; locking them down is done through generic privilege levels and access controls. The people managing those access controls are few, and may not even know the true purpose for the controls they've authorized. Indeed, someone could requisition the insertion of a content analysis system that was fed user data, appeared to be a legitimate deployment, and yet was actually a core service used to push data to the government.
Or their marching orders are to provide live data collection on specific government-identified suspects, rather than live data collection on all users.
In which case, they could claim to be lawfully complying with information requests that are "not as broad", even if the system as designed makes it as easy for the NSA as hitting a "monitor this person" button.
It also wouldn't take vast systemic corporate knowledge. All centralized systems have centralized administrative control that allow for in-depth view and analysis of user accounts and data, and most large-scale systems have relatively powerful and easy-to-use tooling (especially to support customer service, sales, etc).
Complete access to those systems is generally restricted due to the likelihood for abuse, but there remain valid internal management reasons for such access.
Adding to those systems to allow the NSA unfettered (or barely fettered) access could be done without having to alert the entire organization that their internal management systems, which they built knowingly, and have no reason to distrust, have been subverted to allow for on-demand government spying.
It's scary to see how many closet fascists are here on ycombinator.
Most people never review source code, and they certainly don't disassemble and review all the binaries. 'Many eyes' is a security fallacy in cases like this.
When is the last time you heard of the .com infrastructure failing across the board?
Just because you're exposed to some reliability risk doesn't mean that you can't expose yourself to more by using a smaller TLD.
I hope you do. If more of you move out here, the price might deflate to something less completely ridiculous.
> You are so incredibly misinformed. An address book cannot simply be mined. Those are extended permissions and access requires explicit opt in from the user at the OS level before the OS exposes any of that information.
It used to be possible without requiring opt-in. What I've seen in some applications has been piggy-backing permissions -- that is, wait until you have a legitimate reason to request access to the user's address book, location, etc, and then also send that information to your analytics service.
> Furthermore, do you have any data on how much battery, or bandwidth heap uses? No? Ok, please spare the FUD.
Sure I do. They're uploading every 15 seconds, which keeps the WWAN and/or WiFi links up all the time. That can shave at least 25% off of battery runtime (exact numbers aren't easy, given that there are a lot of other factors at play. The basic battery device recommendation is simply: let unused hardware be powered down whenever you can).
There are very limited CPU and battery resources on a mobile device, and it's ridiculous to waste them without asking, specially if you're planning on pushing a massive torrent of mostly-useless data.
> It goes without saying that the user has to be made aware that certain data is collected. I wonder, have you ever heard of a privacy policy?
Ah, right. Put it in the huge document that no user ever reads (because it's huge and unreadable), and that excuses everything.
This is the same argument that sleazy people make in favor of opt-out mailing list spam.
> I agree this is also a good way to ask for permission. Does Apple do this in iOS?
Yep, just once.
> I don't agree that "this user pressed this button at this time" quite fits into the same category of privacy though.
You're going to consume the user's resources by sending that information, and most users don't really want you to (for obvious reasons), so it seems most ethical to ask first.
> What do you suppose the best way to ask for permission is? Please provide actual examples, perhaps from the companies you respect.
Literally ask for permission. That's what Apple does, as does almost every other traditional desktop software developer. On first launch, or when an error occurs, or when some other event that would involve sending personal/usage data to Apple occurs, they:
- Ask if you want to send the data
- Provide details on what kind of information will be sent (including, in some cases, providing access to the data itself)
- ... and usually give you the option to always send that kind of data
Companies I respect (including Apple) ask before gathering usage data; they don't hide it in the ToS that you and I both know nobody will read.
Do you object to asking users? If so, why? My guess is that you know the answer will usually be "no".
See also: opt-out vs. opt-in e-mail spam.
Belief that numbers can be interpreted usefully without a rigorous statistical approach is an enormous fallacy; I don't really see why the burden of proof lies on me.
Once you do apply rigor, you'll find that what the numbers can tell you provides very little help in guiding application design (unless you're optimizing for extremely simple measurable metrics, eg, Zynga).
Note that Zynga themselves copies a full game design, and then applies metrics to optimizing games for addiction and spendthrift response.
The numbers also can't tell you that what you really need to do is rework your application's entire interaction model to cleanly integrate feature X, Y, and Z -- which will also be far too expensive to even attempt to A/B test.
Most analytics users are simply playing an expensive game of "hot or cold".
Then ask the user first. I'm sure that if you can elucidate the value of tracking their every interaction, they'll be happy to agree.
I'll say no, because don't want my battery wasted, my bandwidth consume, my IP logged, my address book mined, etc, just because a PM can't decode where to spend development and design dollars without fudging almost uselessly ambiguous numbers.
When is the last time you read a privacy policy disclosure?
A reasonable person would assume that if an application has no functionality that requires sending data over the network, the application won't surreptitiously spy on you and send your data over the network.
> Aside from using some user resource (like battery or network) how is this different from what website have been doing for a long time?
1) Network requests (and thus communication with a remote machine that can log those requests) is an innate facet of the web. You can't load a site without explicitly choosing to make a network request. An app, however, might have no innate reason to make a network request at all.
I think #1 is the most important, but also:
2) JavaScript can be disabled.
3) HTML/JavaScript and browser network requests can be reviewed. Mobile applications are almost completely opaque to users.
4) Cookies can be blocked to reduce tracking surface.
5) Web analytics and cross-web tracking is already something people are concerned about, resulting in the introduction of do-not-track and similar.
Desktop apps have almost always explicitly asked permission before tracking users, whereas the web community seems to have brought to mobile a blasé approach to privacy and user respect.
For most people, A/B testing a complex app (non-app websites are a completely different beast) is not economical compared to tackling larger (and hopefully obvious) design problems.
If your product is so well designed and developed that there's literally nothing obvious that you can improve without either 1) isolating changes down to colors or placement, and/or 2) throwing different options at the wall to see what sticks, then I say:
Congratulations.
Doesn't make it right. It's also astonishingly user-hostile; wasting the user's resources (bandwidth, battery life, cpu) on things they don't care about, without their permission.
On top of that, doing anything economical with the analytics is very rare. It's very difficult to isolate meaningful variables, and you're almost always better off spending that money paying a designer to tackle issues and features that really ought to be obvious to you already ...
... unless you're Zynga, I guess.
> To achieve the no extra code part, is the SDK using swizzling?
They must be, which is a serious reliability/stability/correctness issue in its own right.
You're keeping the WWAN/WiFi interfaces awake, which burns a significant amount of battery, just because you want to gather data from the user.
On top of that, burning 2% overhead on UIEvent handling (which also impacts battery).
What a waste for something that users don't actually want you to be doing in the first place.
> You learn a ton about social/ ...
That ...
> viral games
.. sounds ...
> and monetization
.. horrible.
> Other init systems are just as bad.
Hardly. Other init systems don't bolt together everything from a (mandatory) syslog replacement to an NFS automounter to a kernel module loader.
> The curious question is why certain projects have significantly lower pull-rates; I doubt the quality of the pull requests vary that widely across projects.
The reverse is more prevalent. The quality of projects varies wildly. The higher quality the project, the less likely that you can accept a pull request as-is.
> Is it that project leadership has a clear vision for a product and feel pull requests are a distraction? If so, share the vision and enlist willing developers to help achieve that vision.
Most developers seem to expect to throw code over the wall in a pull request, and do not follow up to requests for improvement to meet the project's requirements, eg:
- Testing requirements
- Documentation requirements
- Code style
- Ensuring that the implementation fits into the broader project road map
- Code quality
- Avoiding code duplication
- Avoiding code-to-the-goal solutions (see also: project road map).
In my experience, most pull requests take more time to review and correct than it would take to write the code in question from scratch.
> It does take effort and planning but the net result is so worth it to all parties involved.
I don't think the economy is there, actually. Either people are going to read your contribution guidelines and provide quality material, or they're not. Most of the time they're not.
Given my (15 years of) experience in open-source, I'm highly suspect of code quality those projects that have acceptance rates above 50% from people other than core developers.
> Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....).
Technically indeed. If you try to forcibly disable journald, it causes causes dependency failures that result in you dropping to an emergency prompt.
Of course this doesn't stop Lennart Poettering from using the existence of separate but interdependent daemons as 'proof' that systemd isn't a monolithic ball of mud.
> I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.)
Agreed. This is what Apple did with asl(3); it's a modern syslog replacement that happens to still support the syslog protocol and syslog(3) APIs.
There's no reason a modern logging daemon can't be portable to other systems, too; it shouldn't be doing anything so crazy as to be impossible to run elsewhere, whereas since systemd is an intentionally non-portable kitchen sink, no other UNIX is going to run with journald.
> BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested?
You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
> Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths.
No. A proper approach to abstraction:
- Reduces complexity by reducing interdependency between subsystems.
- Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing.
- Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on.
> Might be fine for a lot of projects, but this is just something to boot up your system.
Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable).
Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
> Why can't we have a reasonable non-syslog text format for logs?
I think the real question is: why is systemd defining a logging format at all?
> systemd can boot quite a bit faster than just 5 seconds.
So can other operating systems, no monolithic kitchen sink of systemd required [1].
[1] I realize that having 69 totally interdependent and non-portable daemons is considered "non-monolithic" in systemd-land, but I live in the real universe.
> Actually, launchd replaces init, inetd, crond, atd, and watchdogd.
That's not a "system daemon". Let's break it down:
- init: start/stop services
- inet: start/stop services
- cron: start jobs on a schedule
- atd: start jobs on a schedule
- watchdogd: restart services
Notice the commonality? launchd launches services, possibly on a schedule.
> I mean where do you think systemd got the idea from? :)
systemd is monolithic and system-invasive in ways that launchd never could be, or that anyone wants it to be. Just take a look at the systemd feature list[1]: Quota handling, swap handling, encrypted disk handling, kernel module loading, graphical UI, syslog replacement, console/keyboard configuration, X11 integration, fsck handling, serial console handling, and more!
Systemd is a crazy kitchen sink of a project. It's no wonder that it's non-portable, and I can't imagine trying to evolve the components of a system that came to rely on it. The minute you want to change how an OS subsystem works (eg, such as the automounter), you'll have to dig into the non-portable/non-abstracted systemd code.