<https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines>

<http://link.springer.com/10.1007/978-3-319-16925-5>

The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

It can't. The CONTRIBUTING.html shell would spit out a file and tell the user what Git commands need to be run—just like project READMEs (or landing pages like jekyllrb.com) show which commands will install the tool.

> You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]:

> Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

> Person B: Yet people smoke

<https://news.ycombinator.com/item?id=38712699>

Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser.

If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database".

It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.

They also support deployments from GitLab (so long as you're using the gitlab.com-hosted instance and not a self-hosted GitLab instance). If you've deployed your own self-hosted forge, then you can connect DigitalOcean App Platform to it by using gitlab.com as a bridge—register an account on gitlab.com once and instruct your self-hosted forge to replicate copies to gitlab.com. You don't really need to actually use GitLab.

Having said that, considering that DigitalOcean is in the business of selling IaaS/PaaS, it's loony that they don't let you connect to, say, your own self-hosted Forgejo running on their infrastructure…

(Indeed, considering how many people would like to self-host their own forge but how few people want to actually set up and do admin for it, it's loony that DigitalOcean doesn't pick up, say, Forgejo and/or an alternative and offer a sharply discounted (e.g. $20/year) quasi-managed one-click deployment option with first-class support for connecting to their App Platform.)

It also speculates on the practices at Microsoft in its opaqueness but doesn't recognize the development methodology used for Linux despite its transparency or acknowledge how it differs from the pilloried code review that the audience is most familiar with—even though the kernel development project is the cradle for the VCS that everyone decided to use (but also to never use correctly).

Overall, there aren't really any insights here. The solution described just highlights that high-trust teams are composed of members that (are|can be) trusted by one another. But being on that kind of team is a luxury. The introduction of coding agents doesn't change anything. Take out the LLM-powered patch iteration, and it works for all the reasons it already worked before the advent of coding agents. It's a little like the obliviousness-to-privilege of folks who try to address the problems of people who experience poverty with advice that reduces down to the question, "Have you tried ?"

<https://news.ycombinator.com/item?id=30961588>

Comments URL: https://news.ycombinator.com/item?id=48064709

Points: 2

# Comments: 0

Uh… no.

> setting up native binaries, or native modules linked against the specific Node version

So the majority of projects—those that don't use binary NodeJS modules—don't have a reason for sidestepping the primary VCS and going along with npm's shoddily designed overlay version control approach?

> However, I would just stick with regular pnpm and installs.

You're not answering the question. npm isn't bedrock, and pnpm certainly isn't. If you're going to introduce (mandate) the use of a tool in the workflow, you should be able to justify it by explaining your rationale for introducing it (and making everyone deal with the associated costs). You should at minimum be able to provide a lucid explanation of the tradeoffs. For good measure, you should be able to disprove the "NPM Null Hypothesis"; you should be able to state a straightforward answer to the question, "What problem is this supposed to be solving?"

The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone."

(Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

<https://github.com/w3c/feedvalidator/commit/8ca2fd4e5a520158...>

Comments URL: https://news.ycombinator.com/item?id=48003508

Points: 4

# Comments: 2

<https://remotestorage.io/>

No. That you believed that was just an unfortunate consequence of HN's kneejerk tendency to upvote middlebrow dismissals to the top comment, which resulted in people rushing to craft apologetics for what is in reality bonafide scumminess on LinkedIn's part, which itself resulted in confabulations like the claim that, "It was all extensions related to spamming and scraping LinkedIn last time this was posted"—which is simply untrue.