Hacker News new | ask | show | jobs
by RL_Quine 1306 days ago
> Upon successful submission of a package, the package maintainer will receive an NFT to evidence their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards.

I want literally nothing to do with a cross between a binary distribution tool and a cryptocurrency pump and dump.

10 comments

It doesnt seem we're far away from any mention of "cypto" being a reason to flag (/ report spam).

As the economic recession accelerates, one of its few joys will be the charlatans paying on super-easy-mode being exposed for the useless players they are.

I feel that the major cultish hype-cycle of the last decade is rolling back, and my stress levels are dropping.

Many tech companies are both unprofitable and contribute near 0 value to society. Not unique to crypto. Be careful what you wish for, or the only people left paying software engineers might be non technical companies who pay $80k a year.
Programmers provide high economic multipliers on business activity and are typically in a good position to extract a proportionate reward for doing so.

If we kill off that group of people earning 300k+ in unproductive businesses, all the better. I'd prefer that money be invested in more productive tech, and i'd suppose would generally raise salaries -- since atm, ex hypoth., it is just being burnt

I'd definitely prefer this outcome but I have a feeling we're going to go right back to where we were before as soon as interest rates come back down. Big tech starts aggressively overstaffing again while VCs pour money into mostly useless garbage. I've been doing this for awhile now, mostly in the startup space, and I'm not even sure if VCs care if there's even a viable business there. It often feels like a legal way of running what effectively amounts to a ponzi.
sure, SPAC IPO = dump part of pump & dump

However, just as ponzi in fiance was culturally and legally pushed out --- i'd imagine it will now in tech.

I suspect regulation and cultural scepticism will arise which secures the next two or three decades against this, 'as a rule'

How do you define "unproductive businesses"?
$80k a year is totally reasonable comp for something one can learn in 1-2 years and pretty much master in another 5.
Given home prices are what they are now, I don't really think it's reasonable for mid or Sr level engineers making less money than what's required to afford a mortgage
What about people who cannot code, can they afford mortgage at all?
Probably less than half in the United States now sadly
Love to irreversibly lose control of my packages because of a phishing scam or a buggy smart contract!
LMAO the supply chain attack potential is epic. Oopsie the author of leftpad clicked the wrong button and now an unknown entity owns their package and just updated it with malicious content!
How is this different from our current signing key system?
My signing keys aren't tied to obscure 'smart contracts' that execute code when I do things like try to delete them.
If you are pwned you can contact pypi and get it fixed
Regular phishing. Oopsie!
No such a thing as a buggy smart contract. The contract is right by definition, and that is what was agreed upon. Therefore, it’s the humans who signed it who are buggy. Or something.

I wish I was joking.

I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.

The first thing I was ever taught in my formal CS education is that the computer is (nearly) always right -- if there's a bug it's the programmer's fault. How is that not the case with a smart contract? How is that not the case in the real-world when there are loopholes in laws and contracts? Obviously you can always ask the courts for remediation in the real-world, but let me please point you to many examples where courts make an incorrect/unreasonable decision.

> I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.

It is factually correct, and I also have an issue with it, yes. “There can be no bug in a smart contract by definition” is at the same time true and ridiculous. My problem is using this as contracts, which are agreements between two faillible human beings. In reality, mistakes are everywhere and we have fairly robust ways of dealing with mistakes in contracts. In contrast, what would be a bug in any other situation becomes the truth, with no recourse. This is typical of 2 fallacies in some tech circles: every problem has a purely technological solution, and we don’t need those old fashioned real-world institutions.

Smart contracts are a very fancy hammer when we’d need a screwdriver.

OTOH, I don’t have anything against willing participants having fun with smart contracts.

How does creating this NFT cause it to have value, and therefore reward the package maintainer? If the issue is that no one is putting money into the system, the solution can't be a more complicated way of ensuring that the non-existent money goes to the right person.
Isn't the email proof of ownership. Why do they need an NFT? The owner can change the email to another one when no longer wants to manage.

NFT seeems an overkill and author drank too much crypto-aid.

Not everyone runs their own mail servers.

This is no different from requiring proof of identity using an SSH key like you do with GitHub.

What makes you think this is a pump and dump scheme? Other than the word blockchain
The website linked, and it's associated information all absolutely scream red flags and is functionally similar to a hoard of other schemes. It's a technically simple product (distribute binaries from a webserver) with a completely arbitrary cryptocurrency stuffed onto the side, allowing for bombastic, buzzword filled claims which just defy reality. It attempts to promote itself by driving users who will get some form of profit sharing as part of their participation, promising some sort of rewards paid by the creator.

> Package maintainers will publish their releases to a decentralized registry powered by a Byzantine fault-tolerant blockchain to eliminate single sources of failure, provide immutable releases, and allow communities to govern their regions of the open-source ecosystem, independent of external agendas.

It's existence is an attempt to justify the creation of yet another cryptocurrency, not as a serious solution to any problem that exists in distributing software.

Is the fact that many maintainers burn out and earn no money and little recognition not a serious problem?
That isn't a fact.

Keep in mind that this scheme wouldn't reward the authors of software -- it rewards the people who create and upload packages. Those usually aren't the same people, and the maintainers that are most subject to burnout are the authors, not the packagers.

It also appears to require those developers to purchase (or otherwise acquire) tokens before adding software to the packaging system.

> Keep in mind that this scheme wouldn't reward the authors of software -- it rewards the people who create and upload packages. Those usually aren't the same people, and the maintainers that are most subject to burnout are the authors, not the packagers.

It creates an incentive to package software for the ecosystem, which is a pretty good goal to achieve for a package manager -- especially a brand new one where it would be hard to gain traction without a large number of packages.

I see that as mainly a social problem, not a technical one.

I've noticed that a lot of crypto enthusiasts tend to reach for technical solutions without understanding the social causes of the problem in the first place

This will pay them in quatloos, not money.
Many people will get some satisfaction out of it, if they only receive points or badges. Look at Stackoverflow or GH stars.
Those people are already getting paid in GitHub stars. Adding United Fruit Company dollars to the mix doesn’t make the compensation any more real.

What money will be entering this ecosystem? Absent funds flowing in, how will package maintainers be able to convert their tea bucks to something they can pay rent with?

Yeah those GitHub stars really help with burnout. When you're wading through a hundred pointless PRs of people trying to pad their contribution stats, those GitHub stars just release all the tension.
yes indeed, which is why it deserves a serious solution and not this.
I think a bias against crypto is clouding your argument. Reading the whitepaper makes me wish Bitcoin had never existed, given I imagine plenty of people would apploud many of the ideas in it.

With all the flaws of npm, people do want to be able to have a immutable, mirrorable package-repository with a trust framework they can independently confirm. This does that, along with clever extras like "tasters" who stake a certain amount of value before confirming a package does x.

It's.. sad, that any tech that uses blockchain is now doomed to flag-death because of everything. I get it, but can't help but wonder how I'd have felt reading this paper 10 years ago.

The word NFT
I don't doubt that the author if tea is well-meaning, I think the issue is how it's going to get used, which is what the other poster was referring to.
Being associated with Binance.
I was excited until this crypto NFT bullshit. Smh.
Where is this mentioned? I was getting all excited reading the README file of tea until I saw this comment. Thank you!
On top of which I want literally nothing to do with Max Howell. He's the consummate brogrammer douche. Whined about getting asked to do a code exercise at a google interview, bragging about how he made a project in use by X percent of the company's engineers.

He should go to a few conferences, introduce himself under another name, and bring up brew. I'd guess after half a dozen encounters he'd stop incessantly bragging about being the creator of brew.

Everyone uses brew because they have to, not because they want to.

I'm torn between the brew team being full of insufferable people because they don't know this, and arrogant because they do know it...

> Everyone uses brew because they have to, not because they want to.

What?

Homebrew is easily one of my favorite pieces of software. It's the first thing I install on any new macOS or Linux machine.

Almost every piece of software I want to install is easily installable via Homebrew. The versions it has is almost always more up-to-date than what's in apt or yum. On macOS I can install all of my GUI apps with Homebrew Cask.

I have my Brewfile with my dotfiles so that any time I get a new machine it's easy to install everything I need. Just this week I updated my dotfiles to install Homebrew + my common development utilities on GitHub Codespaces. Without Homebrew I'd have a long, long, long script downloading packages from source verifying keys, installing dependencies, and then finally installing some software.

Aside from that, there are alternatives to Homebrew. Install things yourself from source, or use MacPorts.

> Whined about getting asked to do a code exercise at a google interview, bragging about how he made a project in use by X percent of the company's engineers.

My guess is that you support the status quo of software engineering interviews. That's fine, but many don't.

Why do you have to use brew - there are other package managers for macOS new ones like nixpkgs and ones much older than brew like Macports and Fink. All of these follow normal Unix standards e.g. like work on a multi user system.
Because Homebrew is unfortunately "the standard" and the first place a project will package for if availability for macOS is desired. As a Linux user, it's the worst package manager I've ever experienced but it is what everyone is using in my company who uses macOS (most people).
MacPorts is actively supported, with broad package support — and of course, pull requests for new packages are welcome.

v2.8 was just released on October 20th; changelog here: https://github.com/macports/macports-base/blob/v2.8.0/Change...

"pull requests for new packages are welcome" is the self-defeating answer: if you as a user have to create a PR for a package to be in MacPorts then it means that MacPorts have not attracted enough attention from the authors of the package to submit it themselves.
Very few package authors create packages in any packaging system. The ports are usually done by someone else often part of the package team.

e.g. who crates emacs or vim packages for debian nix etc?

What are your complaints?
It's so slow: on the order of single digit minutes to a dozen to install a single package. It feels messy, like it's shotgunning my entire system with bits of itself (I don't know how true the reality of this is). I've not infrequently had packages simply fail to finally resolve after they did their dance of resolution. It does not inspire delight. The vibe, if you'll excuse me, is very crude cudgel.

Oh, the install location it asks you about when installing Linuxbrew is extremely odd. One choice offered is to make a dedicated brew user directory and then install there? That's terrible practice. No one else does this because it's terrible. And then the other apparently breaks a bunch of stuff and is not recommended.

You don't absolutely have to use brew, but there's a sort of relentless soft pressure to use it because it's more or less the de facto standard package manager for macOS and has such a large collection of packages.

I rather dislike it, and I periodically purge it from my system. So far I've always ended up reluctantly adding it back because I was trying out some tool or other that was dramatically more of a pain to install without brew.

I can get by for a long time without it, but then I want to try out something that assumes brew, or whose dependencies assume brew, and it winds up back on my system again until I get vexed enough to remove it again.

> it's more or less the de facto standard package manager for macOS and has such a large collection of packages

I definitely see the social pressure. That said, I’ve never needed to use it because I needed a package that was not on Macports. So far for my use no difference in the number of packages in the default repositories has been meaningful.

The thing that always makes me cave and install brew is I want to try some tool and its default install assumes brew.

Now, I'll bet in close to 100% of cases I could get things to work with stuff from MacPorts instead, but I've accumulated thirty years worth of scars that incline me to want to stick as closely as possible to the defaults when trying something new.

So I end up going back to brew, even though I don't much like it.

> [Max Howell] should go to a few conferences, introduce himself under another name, and bring up brew. I'd guess after half a dozen encounters he'd stop incessantly bragging about being the creator of brew.

I share your opinion of the technical execution of Homebrew— probably anyone with a deep Linux background would. But I think Howell is well aware of those deficiencies by now (and many may even have been clear to him at the start).

I also think that it's worthwhile for us haters to take seriously what Homebrew gets right, and that means admitting that it's a tool that many, many people have experienced as pleasant and useful. The tidy subcommand interface, relative simplicity, choice of popular/trendy tools (Ruby, at the time of Homebrew's creation), inviting and consistent (if controversial) use of metaphor, and playful tone (small jokes on the docs, use of emoji in CLI output), are all things that have proven to make a real difference in Homebrew's success. None of those speak to package management fundamentals, but they're real strengths and they are visible to all users of Homebrew right away, whether they know much about package management or not.

I feel you about being basically forced to use Homebrew, though. That sucks. It's frustrating to feel hampered by the tools your team uses when you know there are better ones out there but you just can't reverse the team's inertia.

This feels like an uncalled for ad-hominem attack. Also, I might be in the minority, but I actually _like_ brew?
I also like brew. The whole UX pipeline is smooth, and I don't mind if it takes an extra 30 seconds to install packages (which doesn't happen often).

The brewfile (as someone mentioned) is super convenient, and the fact that I can use the same package manager for mac and linux is nontrivially awesome.

To be fair this is kind of a cool idea which is to allow open source package maintainers to earn based on popularity, the incentives here seem interesting at least.

However I highly doubt the original intention behind the NFT collaboration was altruistic to begin with.

Meaning at this point I don’t really trust any altruism in crypto in general (“hey we’re not trying to scam you we really are trying to change the world”).

The idea itself though was interesting to me: getting paid on a token based system for maintaining your open source package

Didn't find any reference in the readme, but was almost sure it's crypto-related the moment I saw the header image; the silly design style is so endemic that it simply shouts crypto on the visitor's face.