Hacker News Reader

Comment by ThePhysicist | Hacker News Reader

I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different. That's the open-source idea even, no? Freely reuse and build upon the work of others, so that we don't have to reinvent things again and again.

View on HN

And yet open source is constantly reinventing the same things over and over again anyway.

I think parent's complaint is that Debian's model has failed to produce good solutions of its own, and while that isn't necessarily a requirement, it does speak to potential limitations of the model

> it does speak to potential limitations of the model

The parent compared a group of volunteers with the largest open-source company in the world, which is a part S&P 500. No other Linux distribution has a comparable amount of resources. Even Canonical is following the RedHat's lead (systemd, Wayland, PulseAudio).

So by your logic, Microsoft and Apple make better OSes than Linux by several orders of magnitude.

In terms of out of the box stability and support? Yes, absolutely.

The power and flexibility of Linux comes with the cost of a much lower floor for stability than proprietary operating systems. You can make a rock solid system using Linux, but that requires nontrivial effort and knowledge. I have yet to see an issue on my personal Windows and macOS machines that approached e.g. package management hell on Linux, in terms of complexity and frustration.

For examples of what open source projects look like when they have the backing and resources of large companies, look at LLVM versus GCC, BoringSSL versus OpenSSL and CentOS versus Ubuntu. "Better" would be too broad a description, but if you qualify it to the narrow scope of stability, then yeah I think proprietary resources generally come out ahead. I also don't think that is a controversial observation.

I don't really desagree with you [0].

I was merely poking holes on parent's theory that more paid engineers and a bigger market cap, somehow justify better technical decisions. That's a dubious thing to say and if extend the logic to the OS level it should be apparent.

[0] I use Windows, Mac OS, Linux (and Android, iOS) all the time, and honestly they all get the job done, but all suck in particular and annoyingly unique ways. So I don't really agree with you either.

Can't seem to be able to edit on mobile:

I meant that the logic fault should be apparent even for a free software advocate, that more resources and paid programmers do not necessary mean better solutions.

So the excuse that red hat has more resources therefore a better process than Debian should not really mean anything for someone I suspect is a free software advocate (the GP)

> In terms of out of the box stability and support? Yes, absolutely.

Support, maybe, if you equate support to "You bought a corporate license so you're entitled to talk to a human being with something more than a script and a mandate to act as a meat-shield."

Stability? That's a term with two different definitions: Doesn't crash, and stays the same over time, with no "breaking changes" even to the UI. Windows... kinda got better at the first, over time, and actively isn't interested in the second, given how much change its UIs have gone through. Remember how Windows 95 worked and acted? Want to replicate that on Windows 10? Remember COMMAND.COM? Is PowerShell a drop-in replacement? I'm not saying COMMAND.COM is better, I'm just saying your old batch files won't run if you only have PowerShell, innit? Ditto COM versus .Net versus... whatever they'll have in five years.

Meanwhile, I've been running WindowMaker on Linux with zsh for over a decade now.

I agree that preinstalled OSX and Windows offer a better end-user experience. I disagree with some of your other statements though.

> In terms of out of the box stability and support?

How many devices have you used that came with Linux "out of the box?"

> package management hell on Linux

This is actually amusing to me. Windows has had this problem for a long time, they call it DLL Hell. Their solution was to duplicate everything and also to have multiple libcs that are incompatible with each other. Developers seem to forget this exists until they actually try to ship something on Windows. Nowadays, companies will just ship all of their dependencies they need.

Reasonably, developers are reticent to do this on open-source platforms, but this is what results in package friction. Semantic versioning would also fix this, but it's unrealistic to think we could get the tens of thousands of packages in a distribution to follow this. I personally don't think Snap or Flatpack is the answer here either, but Nix is.

Sidenote, I'm curious how you got into "package hell." I generally think things from outside the distro-provided stuff should be installed into /opt. Would you install things into System32 on Windows? My guess is that you either added an additional repo, or you installed a packaged generated by some open source code outside of any repos.

Except my understanding is that the amount of manpower involved in the Linux kernel is greater than that involved in the Windows kernel. (Does Apple do kernel development at all?)

RedHat wasn’t always as big as it is now. In fact, it was likely smaller than Debian, in terms of manpower, for some time. I suspect the total number of package maintainers is still higher on the Debian side.

Probably at least partly by necessity. Not everyone participating is doing it as their FT job. I'm sure that RedHat is paying a lot of devs to work on these things as a full time job. Even just integrating software from others as packages, etc.

Also the number well maintained packages is much higher.

The way I understood the parent is that the Debian model didn't actually solve the problem it was suggested as a solution for. It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution. That's how I understood it.

> It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution.

Debian isn't more dependent on RedHat than any other Linux distribution is. It has nothing to do with the governance model, but rather with the fact, that multiple open-source solutions created by RedHat employees and firstly released in Fedora have won as currently the best.

I don't think there's a good way to measure Debian's contributions outside strictly packaging its distribution.

If a Debian developer, or a group of Debian developers, sets out to solve some problem that isn't Debian-specific, the result is (quite correctly) seen as a new independent free-software project rather than a Debian project.

For example, as I understand it the reproducible builds project (now reproducible-builds.org) started out inside Debian, then became a thing of its own.

Correct. Plenty of Debian Developers work full time on other software projects. Very often with synergies with Debian.

Yet there's no obvious way for people to realize to what extent Debian influences other projects and companies.

And yet open source is constantly reinventing the same things over and over again anyway.

That's endemic to programming and the fields around it, even in closed source. I don't think it's a problem of open source, though open source might enable it in a few ways.

In other words, you think if Debian had a larger, more vibrant community it would take in fewer "good solutions" from other projects and instead decide to create its own alternative good solutions in house?

I think this is the first time I've heard someone critique a model for encouraging anti-NIH syndrome.

> I think parent's complaint is that Debian's model has failed to produce good solutions of its own

Debian must be producing very good results, and doing so consistently. Otherwise Debian wouldn't be either the most successful linux distro or the distro that is forked by the vast majority of leading distros.

> I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different.

But that's exactly what Red Hat has done in a lot of situations. The main example I can think of is systemd. It was built to solve problems that really only appear on enterprise production systems, sadly it got adopted across the board for systems outside of that niche. Essentially it's taken what was a working system (sysV init and friends are very, very simple to configure for 90% of the desktop configurations) and replaced it with something that somehow needs continual firefighting.

Back to the original point: Not only has systemd reinvented sysvinit, but at this point systemd has reinvented from scratch:

* The UEFI bootloader[0]

* syslog daemon[1]

* DNS[2]

* A Calendar / cron[3]

* A text editor[4]

* netcat/socat[5]

* nice(1) [6]

* sudo(1) [7]

[0]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...

[1]: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1...

[2]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...

[3]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...

[4]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...

[5]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...

[6]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...

[7]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...

The claimed reinvention from scratch of a text editor, and the nice command, are in fact nothing of the sort. One is a means for invoking a text editor (of one's choice) against particular configuration files, no more a "reinvention from scratch" of a text editor than the vipw command is; and the other is one of the several settings specifying eventual service process state, and is no more a reinvention from scratch than the Service Access Facility's "ulimit" built-in was in 1988.

* https://docs.oracle.com/cd/E19683-01/816-0214/6m6nf1of0/inde...

This is one of the standard parts of service management, and service management toolsets all have to do it, either employing nice or their own mechanisms. Gerrit Pape's toolset does it with the -n option to chpst, for example.

* http://smarden.org/runit/chpst.8.html

Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.

* https://packages.debian.org/stable/editors/

* http://www.guckes.net/vi/clones.php3

Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.

* https://news.ycombinator.com/item?id=17808251

* https://news.ycombinator.com/item?id=17005677

> Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.

> Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.

My response to both of these are, can you point out any of them that are part of a monolithic system that replaces the traditional PID 0?

Or are you talking about people reinventing small parts of the general system? Yes. UNIX allows people to swap out software for other software. In the original use-cases though, the editor(1), cron(1), and nice(1) were at no point conjoined with the boot menu system, or PID 0.

Indeed, there is a fundamental choice between someone building a replacement for one small part of the general system, to make their life easier, and building a replacement for the entire init system.

Reply on news.ycombinator.com