6 ms·

Thank you for all your work. I installed Debian for the first time almost 13 years ago and have enjoyed the "Debian way" every second. But as the saying goes,

• neuromute 10y ago
  What are you migrating to, if you don't mind my asking?
  • rxlim 10y ago
    FreeBSD, so the migration is not just away from Debian but also Linux. Of course problems always arise in such operations, but in general we have been very happy with the change, and I'm just as excited about FreeBSD as I was with Debian before.
    • gkya 10y ago
      Do you migrate you workstation to FreeBSD too, or your servers and the like only? In any case I want to take this opportunity to note that FreeBSD is quite nice as a daily driver on your workstation. The only missing thing is bug-free suspend/hibernate, which works for some and for some doesn't. edit: added missing adverbs.
      • nerflad 10y ago
        In my experience, you're also rolling the dice when you suspend Linux. My x99 workstation, z77 workstation, and XPS 13 have all failed to resume before. But Windows has done the same. I guess ACPI is a mess.
        • Fnoord 10y ago
          > But Windows has done the same. I guess ACPI is a mess. Of course, you don't mention macOS. I never had issues with suspend on any of my MBPs. If I did, it turned out that was my battery got empty, and the few times this happened I did think about suspend failing. Turned out I was wrong.
          • gkya 10y ago
            Thing is though it's an OS tied to a certain hardware since years. If Apple couldn't provide a seamless experience it'd be pure incompetence.
          • nerflad 10y ago
            Good for you. I've never owned a MBP, and this thread is about switching from Debian to FreeBSD.
            • Fnoord 10y ago
              You completely missed the point. If ACPI is a mess, how come macOS doesn't suffer from the issue?
              • nerflad 10y ago
                Look, I'm sure the macOS implementation of ACPI is great. I said "I GUESS ACPI is a mess", because most implementations I've used (and I've only used it; I know nothing low-level about it at all) have had some problem or another. How wrong of me not to have any experience with your preferred platform, and leave it out of the discussion.
                • Fnoord 10y ago
                  That is why I told the reader (anecdotal) evidence which suggests the contrary. > How wrong of me not to have any experience with your preferred platform, and leave it out of the discussion. No need to feel so overly offended.
• vmateixeira 10y ago
  Mind if I ask what, in particular, is making you move?
  • icebraining 10y ago
    I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.
    • SteveNuts 10y ago
      I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.
      • icebraining 10y ago
        I know I pulled it in, but I was hoping to avoid another systemd discussion myself, just trying to answer vmateixeira :)
      • Z-Widwil 10y ago
        Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.
        • barrkel 10y ago
          Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the dependencies between the services (replacing init-scripts). Systemd is more complicated but can do more stuff, like initialize things concurrently. Functionality that used to be implemented in services themselves (e.g. restarting, recovery) is migrating into systemd, and systemd is acquiring more and more logic. Some people feel that this is contrary to the *nix philosophy and is not architecturally sound. Operationally, instead of using shell scripts and symlinks designed to be sorted in a particular order (normally maintained using other tools), you use descriptions of how the service should start and what it depends on. Security-wise, systemd is a bigger hairier ball, so it probably has bugs. But it also implements stuff once, whereas before implementations were distributed and of variable quality. So the variance in security level is probably lower with systemd, but depending on your mix of services, the mean may be higher or lower. And you don't get to control it.