The "perceived benefits" of being able to see more things at once might really be an illusion if they're just a firehose of distractions.
Less so when the things in question are "an error log next to the bug I'm filing about it", or "program output and the program I'm iterating on" or "the total state of production while I'm deploying code" or "chat with team members while I'm reacting to an incident and don't have the mental bandwidth for extra context switching". A really powerful tiling WM with desktops that can be independently switched between a couple of monitors is pretty much a superpower in these situations.
TFA seems overconfident and mistaken in its assumptions.
The reMarkable is a very impressive piece of hardware with unfortunately bad software and a business model that looks to be deteriorating (see recent moves to subscription services, etc.).
In physical/tactile terms, it's a really impressive writing experience, but I've found the utility of that so constrained by the absence of indexing and navigation features that I don't use it for much besides occasional drawings. It turns out that navigating a physical notebook works in ways that flipping through electronic pages can't keep up with without a lot of work on the interface.
As an e-reader, recent updates to the rendering have made it usable, though there are still sometimes hassles with display and getting documents onto the device. It's theoretically great to be able to annotate PDFs, but in practice not being able to easily navigate the annotations later makes it substantially worse than writing notes in the margins of a paper book.
I'm sure a lot of this can be improved with 3rd-party hacks, but it isn't designed as a platform and it feels only grudgingly open to modification, which seems like a huge missed opportunity. (Not to mention being yet another product built on open code that doesn't return the favor.) Being able to SSH to the device and poke around the filesystem is cool, but it mostly feels like a glimpse into how much more utility the whole thing could offer.
I'll use mine as long as it works, but I'm unlikely to buy another one and I can't in good faith recommend it for most users. I do know several folks who are happy with the narrow range of things it's good at, which is why I bought it in the first place. Personally, I'm placing my hopes for a more useful-to-me e-ink future on devices like the PineNote.
> I also noticed that while they do appear to use pylint to enforce good standards, almost all source files have at least one check disabled...
I haven't touched any of the CircuitPython hardware libraries in... Well, something close to two years by now, I think. A lot has probably changed. Still, when I was last involved, placating pylint was consistently a hassle.
As I recall it squawks about things like identifiers that don't conform to snake_case. All well and good as a general stylistic suggestion, but not especially helpful when that's what the thing is called.
There may be some bad ideas lurking in places where those checks are disabled, but in general I blame no one for disabling one or more of its checks in service of greater readability or better code layout.
> In one of this paper's experiments, for instance, a computer split a pot of money between itself and a human participant; this person was led to believe the computer was also a human participant. Sometimes the pot was split unevenly, and the human participant was given a chance to take vengeance by reducing the computer's pot without enriching his own. Researchers discovered that participants classified as having higher TIV scores were "strongly associated with behavioral revenge" in this scenario.
In retrospect, dictator game allocation scenarios presented to a pile of undergraduates by way of a screen were probably nonsensical back when I was helping my social science grad student friends implement them as crappy Perl CGI in like 2003. I'm disinclined to expect much better from this one.
Version control for a genuinely long-lived project is a problem that often outlasts:
- Dominant version control and code review system(s) / paradigms.
- The current configuration of institutional owners.
- Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.)
- The involvement of developers who remember why and how decisions were made.
- The trustworthiness of the entities that control services, applications, and network real estate used for development.
Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users.
If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.
> You think we could develop a unified data model that covers source code, static files, documentation, project management and community management as a single unified thing?
Realistically, not exactly, given how much space some of those things cover.
I do think that entities like code review are as much a part of the history of a project as the deltas to code. Reviews not being first-class objects in the VCS itself has turned out to be a crack into which you can wedge an entire GitHub.
I won't claim I know where best to draw the line here. Better handling of large static files by default and a robust way to model relationships between projects obviously belong within the VCS. On the other hand, relationships modeled in issue tracking systems and the like are also part of the software's history, but past some level of complexity it gets much harder to imagine wedging them into something that you can pass around like you clone a Git repo. All I can really say for sure is that it feels broken that all of this stuff lives in competing application silos.
(As a sidebar: Not that you can't jam things like review data into git-as-data-store. Gerrit does just that. But nobody's going to mistake that for a usable interface to code review.)
Anyhow, I don't think you're wrong about the social & economic factors, but I think a different landscape with less concentration of power could have shaken out if (for example) easy code review had been baked in and host-agnostic early on. Fully p2p architectures aren't feasible, or even necessarily desirable, for a lot of problems - but it shouldn't be too much to ask that things are able to be federated and resistant to capture by a single vendor.
> Still... I completely agree that it would be awesome to have a more self-sovereign computing architecture writ large. I’m just pessimistic we can get there from here.
Yeah, fair enough. I am myself boundlessly pessimistic about the future of computing generally.
Yeah, from that angle and from the perspective of 2005 it's a reasonable design, and I think what I describe above as a massive deficiency only really becomes visible in the light of everything that's happened since.
We recently conducted an extensive evaluation of CI options[0], concluding at the time that GitLab could meet our needs but didn't make a whole lot of practical sense unless we also migrated to it for code review. Other considerations (Gerrit user experience and sustainability, onboarding costs, a de facto migration of many projects from our Gerrit instance to GitHub, etc.) led us to re-evaluate whether a migration for code review would make sense, and that's what the decision linked here addresses.
I am on the team that maintains our existing CI system[1] (Zuul, Jenkins, JJB), though I mostly work on other things. While this system is certainly quite powerful, I would not personally describe it as easy. We have a lot of work in front of us in migrating it to GitLab, but so far I've found the experience there quite a bit more pleasant than grepping through JJB definitions and the like.
At any rate, if you're interested in how all of this pans out, we will as ever be doing the work in a very public fashion.
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in.
A few paragraphs I recently wrote elsewhere:
The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in design.
I rant about this all the time, but there is an entire class of argument about how & whether to use GitHub / GitLab / Gitea / Phabricator / Gerrit / sourcehut / mailing lists / whatever that would mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Because it's not, we find ourselves in a situation where no widely used DVCS is actually distributed in practice, and the tooling around version control is subject to platform monopolization by untrustworthy actors and competitive moats.
Code review should itself be distributed/federated, but few of the people involved have incentives to make that happen. It's possible something like https://github.com/forgefed/forgefed will eventually get traction, and Git has been dominant for long enough that I wonder all the time when we might see a viable successor that learns from its fundamental mistake. In the meantime we're forced to choose from a frankly pretty terrible lot of options in the broad structural sense.
(For clarity, I'm a WMF employee and am involved in the decision to migrate to GitLab.)
Given that very nearly the entire software industry has either acquiesced to or actively abets practices like these, the real answer is generally "desperate enough to be seeking a job in your field".
I sort of want to engage with this. I understand that people have good-faith qualms about the fairness of hiring practices intended (implicitly or explicitly) to increase diversity and access. There are problems to wrestle with here, and it's inevitable that some bad actors will take advantage of attitudes like Pike's (or mine).
And yet: I don't have the sense that I'm going to get anywhere by acknowledging the problematics of the thing. There's just too much committed misogyny embedded in this community as a whole. It feels like a safe bet that "I don't need to listen to women" may as well be the entirety of this particular comment, and many of the others in this thread.
I've been feeling conflicted about participating in comment threads on HN. This one is enough to convince me that I should stop investing the energy.
As I've asserted a few comments over, there's an ample body of detailed, firsthand observation available to men who are sincerely interested in the problem. It's also possible for us to talk to women who work in the field and listen as they describe their experiences. The existing gender imbalance, routine discrimination in hiring and promotion, rampant harassment, and profoundly toxic social dynamics are all recurring themes.
I don't seem to meet a lot of women who feel that there is a dearth of evidence about any of this.
Meanwhile: This embarrassing trainwreck of a thread, ad infinitum.
Less so when the things in question are "an error log next to the bug I'm filing about it", or "program output and the program I'm iterating on" or "the total state of production while I'm deploying code" or "chat with team members while I'm reacting to an incident and don't have the mental bandwidth for extra context switching". A really powerful tiling WM with desktops that can be independently switched between a couple of monitors is pretty much a superpower in these situations.
TFA seems overconfident and mistaken in its assumptions.