5 ms·

And yet they take in many of RedHat solutions and decisions... mostly due to lack of manpower for the alternatives I suppose. Design by committee is avoided by

And yet they take in many of RedHat solutions and decisions... mostly due to lack of manpower for the alternatives I suppose. Design by committee is avoided by using designs of someone else.

kibwen 8y ago
Every design either comes from one person, or it comes from a committee. A project like Python has long since scaled far beyond the capability of one person to feasibly design. The same is true of any other major (or minor) programming language. Vague anxiety about design-by-committee is always in vogue, but it doesn't do us any good.
simonh 8y ago
And RedHat takes projecys ftom upstreams they don’t contribute to and bundle them in their systems. Sorry, but this is a particularly mean spirited attitude. The open source model has always been to share your work On one hand and selectively use others work yourself where it makes sense. That’s what opens source is for. It’s what it means. BSD is free to commit their resources to those areas where they feel they can offer value or meaningful differentiation, and they do so.
ThePhysicist 8y ago
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.
- AnIdiotOnTheNet 8y ago
  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
  - krn 8y ago
    > 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).
    - iosonofuturista 8y ago
      So by your logic, Microsoft and Apple make better OSes than Linux by several orders of magnitude.
      - deleted 8y ago
        [deleted]
      - deleted 8y ago
        [deleted]
      - throwawaymath 8y ago
        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.
        iosonofuturista 8y ago
        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.
- fao_ 8y ago
  > 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/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L1306 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [1]: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1234 http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1... [2]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1128 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [3]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1044 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [4]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n689 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [5]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L546 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [6]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L425 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [7]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L1233 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
  - JdeBP 8y ago
    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/index.html 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 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/ https://packages.debian.org/stable/editors/ * http://www.guckes.net/vi/clones.php3 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=17808251 * https://news.ycombinator.com/item?id=17005677 https://news.ycombinator.com/item?id=17005677
belorn 8y ago
Last time I was a debconf, one such decision was basically 20-30 interested people sitting in the room and the speaker says "We need more people if we want to maintain and develop X, or could switch over and use Y. What is the progress on packing Y?". It was a rather simplistic process by the developer who is doing the work and anyone interested that wanted to show up. Debian leadership rarely get involved in such decisions.
debiandev 8y ago
> And yet they take in many of RedHat solutions and decisions Citation needed - that's simply not true.

And yet they take in many of RedHat solutions and decisions... mostly due to lack of manpower for the alternatives I suppose. Design by committee is avoided by using designs of someone else.

kibwen 8y ago

Every design either comes from one person, or it comes from a committee. A project like Python has long since scaled far beyond the capability of one person to feasibly design. The same is true of any other major (or minor) programming language. Vague anxiety about design-by-committee is always in vogue, but it doesn't do us any good.

simonh 8y ago

And RedHat takes projecys ftom upstreams they don’t contribute to and bundle them in their systems. Sorry, but this is a particularly mean spirited attitude. The open source model has always been to share your work On one hand and selectively use others work yourself where it makes sense. That’s what opens source is for. It’s what it means. BSD is free to commit their resources to those areas where they feel they can offer value or meaningful differentiation, and they do so.

ThePhysicist 8y ago

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.

AnIdiotOnTheNet 8y ago
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
- krn 8y ago
  > 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).
  - iosonofuturista 8y ago
    So by your logic, Microsoft and Apple make better OSes than Linux by several orders of magnitude.
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]
    - throwawaymath 8y ago
      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.
      - iosonofuturista 8y ago
        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.
fao_ 8y ago
> 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/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L1306 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [1]: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1234 http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1... [2]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1128 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [3]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n1044 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [4]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1ca11270e66777c90a449096203afebc37ec9c#n689 https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d... [5]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L546 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [6]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L425 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546... [7]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L1233 https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
- JdeBP 8y ago
  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/index.html 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 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/ https://packages.debian.org/stable/editors/ * http://www.guckes.net/vi/clones.php3 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=17808251 * https://news.ycombinator.com/item?id=17005677 https://news.ycombinator.com/item?id=17005677

belorn 8y ago

Last time I was a debconf, one such decision was basically 20-30 interested people sitting in the room and the speaker says "We need more people if we want to maintain and develop X, or could switch over and use Y. What is the progress on packing Y?". It was a rather simplistic process by the developer who is doing the work and anyone interested that wanted to show up. Debian leadership rarely get involved in such decisions.

debiandev 8y ago

> And yet they take in many of RedHat solutions and decisions Citation needed - that's simply not true.