3 ms·

They're open source, but they rely on so much ubuntu-specific infrastructure and patches that it's infeasible to get them running anywhere else. Cf. the effort

by creshal 11y ago

They're open source, but they rely on so much ubuntu-specific infrastructure and patches that it's infeasible to get them running anywhere else. Cf. the effort necessary to get Unity running on Arch: https://github.com/chenxiaolong/Unity-for-Arch https://github.com/chenxiaolong/Unity-for-Arch You have to rip out and replace a lot of software, all the way down to GTK itself, just to make it work.

vacri 11y ago
Sounds like Redhat's systemd: "if you want to run it, you have to replace most everything."
- creshal 11y ago
  Init systems are, by nature, highly invasive. Systemd's requirements don't fundamentally differ from modern sysvinit derivatives or upstart or whatnot in that regard. Unity, on the other hand, is a bloody desktop environment. You can install dozens of those (or could, if there were that many) in parallel without any modifications… with the sole exception of Unity.
  - vacri 11y ago
    Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. Other init systems don't. You can't just drop systemd in and get by just with learning it's config language - you have to change the way you do a number of other things, too. But then again, you don't think that there are dozens of desktop environments. Arch supports nearly two dozen by itself (https://wiki.archlinux.org/index.php/Desktop_environment https://wiki.archlinux.org/index.php/Desktop_environment), and that list doesn't include things like fvwm, or tiling desktops like xmonad or i3. Edit: To clarify, the point being made is "if you have to modify a bunch of stuff, then the software is not free". Systemd requires a lot of modifications - it's not a 'drop in' replacement. Using the same argument, systemd is 'not free'. It doesn't matter how 'invasive' the component is, the argument is about modification effort. I think the argument is wrong - Canonical patches a lot of things for Unity, but those patches are publicly available and are not done to obfuscate the code. Basically the argument here is that no-one should be allowed to publish free software if it can't be simply dropped into $RANDOM_YAHOO's system.
    - creshal 11y ago
      > Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. From my own experience, migrating machines from sysvinit to systemd is trivial. Systemd does not need all those optional bits and is happy to work with syslog, ntpd, cron, etc. pp., can pass through sysvinit init files, and so on. If you actually use it instead of relying on fudy reports, it's a breeze to work with. Recompiling half my desktop, and then recompiling all userspace programs using any of the involved libraries, is much more invasive compared to that. Another approach is looking at what you have to do when building a system from scratch: Here, systemd's "modification needs" are obviously close to zero (because the system is built around it, you can use journald/timesyncd/etc. from start, or set up rsyslog/ntpd interoperability for systemd). Userland software might, at most, need unit files to use them. Desktop environments et. al. work without dedicated logind support or anything. Unity, however, still requires me to scrape together patches out of Canonical forks of various programs and libraries to get it to work. It's still massively invasive and requires far, far too much effort.

by creshal 11y ago

vacri 11y ago

Sounds like Redhat's systemd: "if you want to run it, you have to replace most everything."

creshal 11y ago
Init systems are, by nature, highly invasive. Systemd's requirements don't fundamentally differ from modern sysvinit derivatives or upstart or whatnot in that regard. Unity, on the other hand, is a bloody desktop environment. You can install dozens of those (or could, if there were that many) in parallel without any modifications… with the sole exception of Unity.
- vacri 11y ago
  Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. Other init systems don't. You can't just drop systemd in and get by just with learning it's config language - you have to change the way you do a number of other things, too. But then again, you don't think that there are dozens of desktop environments. Arch supports nearly two dozen by itself (https://wiki.archlinux.org/index.php/Desktop_environment https://wiki.archlinux.org/index.php/Desktop_environment), and that list doesn't include things like fvwm, or tiling desktops like xmonad or i3. Edit: To clarify, the point being made is "if you have to modify a bunch of stuff, then the software is not free". Systemd requires a lot of modifications - it's not a 'drop in' replacement. Using the same argument, systemd is 'not free'. It doesn't matter how 'invasive' the component is, the argument is about modification effort. I think the argument is wrong - Canonical patches a lot of things for Unity, but those patches are publicly available and are not done to obfuscate the code. Basically the argument here is that no-one should be allowed to publish free software if it can't be simply dropped into $RANDOM_YAHOO's system.
  - creshal 11y ago
    > Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. From my own experience, migrating machines from sysvinit to systemd is trivial. Systemd does not need all those optional bits and is happy to work with syslog, ntpd, cron, etc. pp., can pass through sysvinit init files, and so on. If you actually use it instead of relying on fudy reports, it's a breeze to work with. Recompiling half my desktop, and then recompiling all userspace programs using any of the involved libraries, is much more invasive compared to that. Another approach is looking at what you have to do when building a system from scratch: Here, systemd's "modification needs" are obviously close to zero (because the system is built around it, you can use journald/timesyncd/etc. from start, or set up rsyslog/ntpd interoperability for systemd). Userland software might, at most, need unit files to use them. Desktop environments et. al. work without dedicated logind support or anything. Unity, however, still requires me to scrape together patches out of Canonical forks of various programs and libraries to get it to work. It's still massively invasive and requires far, far too much effort.