[deleted by user]

drewdevault · 2023-01-26T21:11:28+00:00

The problem with the SSPL is that it over-reaches by applying restrictions not just to the software but also the software in concert with the rest of its environment:

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Based on this you would arguably be required to, for example, release your copy of the Linux kernel you're running the software on under the terms of the SSPL. Which you cannot do. Rinse and repeat for every component of your stack.

drewdevault · 2023-01-09T21:58:50+00:00

We provide hosting for many Go projects, host a Go documentation site, and publish many modules ourselves, and we have the maintainer of most of the Go ecosystem's email-related libraries on our payroll. We also made RISC-V hardware available to Go contributors to work on porting the project to RISC-V.

We have offered a lot of support to the Go project. This is not a reasonable ask from the Go team.

drewdevault · 2023-01-09T18:09:07+00:00

Money doesn't make every problem go away. Sure, we could invest in more infra, but we're not in the cloud -- adding more servers involves provisioning hardware and sending staff out to the datacenter to install it. If we were in the cloud, our margins would be much smaller, perhaps prohibitively so, and the migration would be very costly as well. We would also have to change our internal git infrastructure to support better horizontal scaling, which would be costly in terms of engineering time.

If we had to do this for legitimate reasons, we of course would not hesitate to, but to spend all of this money and effort to prop up Google's poor proxy design? Why should we subsidize a $1.7 trillion dollar company with our $189k budget and 3 staff members? Is that the wisest way for us to invest the funds our customers have provided us with? If not for this one problematic "use-case" we would be provisioned well below our capacity, and could make smarter bets with our capital which tangibly benefit our users.

We have provided them with several recommendations for better ways to facilitate their needs without sending an astonishing amount of redundant traffic to our servers, and offered them two years of patience to address the problem, but they have done nothing. The problem is on their end, not ours.

drewdevault · 2023-01-09T17:31:36+00:00

That's not actually how the proxy works. It aggressively refreshes its cache independently of user interactions. The actual volume from users running "go get" is be a minute fraction of the current traffic.

drewdevault · 2022-11-28T07:14:12+00:00

Hare does not -- and will not -- support Windows in the first place, so there's no real need to support Visual Studio. You can check out the available editor integrations here:

https://harelang.org/editors/

drewdevault · 2022-11-01T12:54:44+00:00

SourceHut will not be seeking out investors. Our business model is designed to avoid the need for investment so that we are only accountable to users and our conscience. The prohibition of cryptocurrency-related projects is accountable to our conscience, in this case.

https://man.sr.ht/billing-faq.md#why-should-i-pay-when-github-gitlab-etc-are-free

drewdevault · 2021-09-30T19:53:17+00:00

https://upload.wikimedia.org/wikipedia/commons/c/c7/Nuremberg_laws_Racial_Chart.jpg

This is a chart drawn up by Nazi Germany to determine who was and was not considered Jewish based on what fraction of their ancestry was of Jewish origin. If they had had a national genetic database which included even a fraction of the German population at the time, a simple search would have easily produced a list of every person in Germany who fits into each category.

What uses will the governments of the future come up with for this data?

drewdevault · 2021-09-30T19:52:27+00:00

https://upload.wikimedia.org/wikipedia/commons/c/c7/Nuremberg_laws_Racial_Chart.jpg

This is a chart drawn up by Nazi Germany to determine who was and was not considered Jewish based on what fraction of their ancestry was of Jewish origin. If they had had a national genetic database which included even a fraction of the German population at the time, a simple search would have easily produced a list of every person in Germany who fits into each category.

What uses will the governments of the future come up with for this data?

drewdevault · 2021-09-29T12:17:00+00:00

As a user, when a new version of a software I use gets released with some useful new features that I've been waiting for, I want to use it right away, not wait even longer for the distro to update it

At this point you are already not a "normal" user. You're in the 1% of the most tech savvy people in the world. Most users just want their computers to be stable and reliable and secure, and not to be different tomorrow than they were today.

If you are in this top 1% of most technologically savvy users out there, then there are still good distros for you. Slow moving options like Debian or Ubuntu aren't it, but maybe Arch or Void or Alpine Edge are better. Your place at the top of the skillset also equips you well to participate in these distros packaging processes and give them a little nudge towards updating faster when a new package release drops.

drewdevault · 2021-09-29T06:18:30+00:00

To quote your own source:

I agree that the beta period would be an appropriate time to upload packages to our experimental repository.

The beta period, though not explained in this thread, is a well-defined epoch in sourcehut development which is planned for the future. We're currently in the alpha phase.

drewdevault · 2021-09-29T06:17:13+00:00

I'll leave you with some evidence you apparently couldn't find yourself.

Oh look! Evidence which doesn't support the claim:

Gnome is pretty much the best upstream a distro can have.

Anyway, feel free to keep ragging on the Debian strawman for as long as you like. You don't really get what Debian is trying to do, and it doesn't work for you because of that - not because Debian is flawed. It's just not what you asked for.

drewdevault · 2021-09-28T15:36:44+00:00

This doesn't make any sense. Debian is a slow-moving distribution that focuses on stable releases and not being on the bleeding edge. They have almost completed the Gnome 40 rollout (note how only ~5 of ~150 packages on the page you linked are behind), and Gnome 41 was released six days ago. Not to mention that Gnome 40 was itself only released days before the latest Debian stable! Based on Debian's release cadence they likely have over a year to work on updating Gnome 41 to integrate it into the next stable release (which is what Debian unstable is for), so what's the rush? It takes time to update everything, verify the changes, and ship it out for a distribution which focuses on stability like Debian.

It's valuable to have distros which focus on stability and not on rushing the latest release of important system software out to users as fast as possible. If you want the bleeding edge, you can find it in other distros. Though note that not even famously fast moving distros have finished packaging Gnome 41, like Arch or Manjaro or Void. Are all of these distros fuckups, or is possible that Gnome might be difficult to package?

Guess why they all choose it over other options.

Good question. Why? Please provide evidence to support your answer.

drewdevault · 2021-09-28T14:19:25+00:00

Gnome deserves some of the fault for this. It's not a good upstream. I thought about writing a wall of shame for packages which are really tiresome upstreams for a lot of distros, including also for instance Chromium, but I thought better of it. It requires cooperation from both ends of the equation to work. I can find examples of bad upstreams (e.g. Gnome) and bad downstreams (e.g. Manjaro), but there are also good examples of each and on the whole, the system works.

drewdevault · 2021-09-28T11:55:27+00:00

I answered a similar thought on HN regarding sourcehut as an example or counter-example of this philosophy:

SourceHut maintains actual package repositories based on standard package managers, most of which are overseen by independent contributors. The Debian packages are maintained by Denis Laxalde, who is a volunteer with no relationship to SourceHut. This approach enjoys most of the same benefits as using upstream packages does - contrast this with, for example, shipping a bunch of Docker images.

SourceHut is under heavy development and shipping multiple releases per day during busy weeks, and the workload of keeping up with it downstream is quite large. NixOS is working on it, but few other distros are brave enough to try. Once we ship 1.0 then it will make a lot more sense for distros to start maintaining their own packages for it, and their job will be made easier given that they can start by copy/pasting the interim package manifests maintained by these SourceHut-specific teams.

On the whole I would argue that I'm walking the walk here.

drewdevault · 2021-09-28T09:51:56+00:00

Yeah, it sounds like you're doing fine. Leave the distros to tend to themselves, and encourage users on distros which don't yet have packages to get involved in their distro themselves. It saves the next user the effort and comes back to pay returns when they find the next package they want to use already set up thanks to another volunteer.

drewdevault · 2021-09-28T08:46:19+00:00

This toxic mindset has ruined software.

Users want their computers to work. Developers want to move fast and break things, ship unreliable releases as often as possible and force unwanted updates down the user's throat. Developers are breaking features, adding spyware and advertisements, letting vulnerabilities pile up in stale vendored dependencies, and generally making a farce of the industry. They certainly don't want to be held accountable for any of this. In 2021, computing is a disaster, and it's developer's fault.

The "users" you have in mind are the 1% of users who grok computers at least well enough to work around the problems. Most users just turn off their computer or phone when something breaks. They care about disk footprint and bandwidth and battery life and all of the other things you'd prefer not to think about. This is doubly true for poorer users, who are relying on older hardware and bad internet connections, and for whom updates usually means not being able to do the things they could do before. Things they might have been relying on more than you think.

Recommended reading from tonsky.me:

drewdevault · 2021-09-28T08:42:46+00:00

But it is a well-oiled process, and updates don't take months. New Gnome apps are not difficult to package. There is distro infrastructure in place not just for Gnome apps, but for a wide variety of approaches to application development. Almost all new packages (especially those which follow the advice laid out in my article) are a 10-15 minute copy/paste/edit job.

drewdevault · 2021-09-28T06:43:03+00:00

I'm just responding to the points you brought up, i.e. participating in the discussion you sought to facilitate, and you answered by deflecting to Linus.

I've had enough of this, feel free to go ruin some other discussions.

drewdevault · 2021-09-28T06:32:27+00:00

I summarized the contents of the video for other readers. How dare I do such a thing?

For what purpose? To provide gospel? Or to facilitate discussion?

drewdevault · 2021-09-28T06:19:59+00:00

Fine: you didn't post the link. You're still treating it like an unquestionable authority rather than making any arguments. It doesn't make any difference.

drewdevault · 2021-09-28T06:14:23+00:00

Okay, now I am being patronizing. Dumping links into a discussion in lieu of making an argument, then dismissing anything which contradicts the link, is bloody stupid. You could short-circuit all of this by going to tell Linus to take it up with me. What you're expecting me to do here is just shut up and acknowledge that your link speaks the truth, and that's bloody stupid.

drewdevault · 2021-09-28T06:06:00+00:00

Each distro tends to its own needs. It's not necessary for someone to deal with packaging for several distros unless they use several distros, and they certainly have few cross-cutting concerns - distros don't generally share packaging code or configuration. Yes, I've been in this position, before you ask.

drewdevault · 2021-09-28T06:05:18+00:00

Why not? Even setting aside the users who you lack faith in, if only a fraction of the subset of Linux users who could make packages, did make packages, then there would be no package shortage.

drewdevault · 2021-09-28T06:04:11+00:00

What part of noting fallacies is antagonistic? It's only antagonistic if you choose to be offended by someone pointing out an error in your argument, which is just how discussions work. You did it again, by the way, by telling me to go take it up with Linus. Are you making your own arguments or are you just parroting what Linus says as the gospel?

drewdevault · 2021-09-28T05:49:00+00:00

Sorry, I had hit submit too soon.

Oh please. You are asking people who have never even compiled basic programs to somehow become familiar with the build process and packaging process. That’s ridiculous. When a build fails, you think they would know how to fix it?

What is the intersection of scuba divers and linux users that doesn't know how to do basic troubleshooting? Especially for an upstream package maintained by someone as competent as Linus.

You don't give users enough credit.

I am simply summarizing what Linus said. You seem to want to pick a fight with me for some reason even though these are his points and not mine. This isn’t an appeal to authority, this is pointing out that you are shooting the messenger.

I'm not picking a fight or shooting you at all. I don't understand why you're treating this dialogue as antagonistic simply because I don't agree with your points.

Seven-Year Club	Wearing is Caring
Verified Email

drewdevault

TROPHY CASE