Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

Post reply on HN
Print view View original

201–210 of 464 posts

Re: Systemd redux: The end of Linux

#201

Post by vidarh »

SwellJoe wrote: post #138
threeseed wrote: post #135

Earlier quoted context omitted.

> What hacker chooses to be beholden to Oracle ? How about almost every single Java, Scale, Clojure etc developer. We are all using Oracle's JVM and they have been unquestionably a fantastic steward of the Java platform. I know the company deserves a lot of criticism but remember it is a big company with many different departments.

Fair enough. I haven't followed Java in many years (long before the Oracle acquisition), so I don't have any point of reference. In my mind, and in my experience, Oracle make Microsoft seem like pretty nice guys.

Ellison seems to have had a pretty solid inferiority complex when it comes to Gates. He must be pleased with how Oracle has now dethroned Microsoft as the Evil Empire, seeing as how even most hardened old Microsoft haters (I count myself in that group) now for the most part has at most slightly tepid lingering dislike for Microsoft, while Oracle has taken the exact opposite part.

Re: Systemd redux: The end of Linux

#202

Post by dijit »

lucian1900 wrote: post #158
makomk wrote: post #146

Earlier quoted context omitted.

Yeah, and they seem to be using Windows as their model of what a "real operating system" looks like.

Both Windows and OS X have a unified management mechanism. In fact, OS X's launchd was a direct inspiration for systemd because of how nicely it works there. I've wanted launchd on servers for so many years.

OSX is not an appropriate choice for a server, and Windows has limited reputation in my mind since they put the GUI in kernel space.

we should not emulate the things we've overtaken and have a higher server market share than. Something we've been doing before is doing it right, and I believe it's the ability to be dynamic and modular.

Re: Systemd redux: The end of Linux

#203

Post by vidarh »

nisa wrote: post #58
rodgerd wrote: post #56

Earlier quoted context omitted.

Here's a though: try remembering you don't speak for "sysadmins", you speak for yourself.

I think he speaks for sysadmins. If you are using cgroups at the moment you can write scripts for them. It's a mounted filesystem. The change forces you to use systemd for cgroups as only systemd is able to write to cgroups. The argument is: If you don't like systemd implement an alternative that does this for you. Some for kdbus and udev, netlink... The article is right - it's not Linux as we know it anymore for bet…

He doesn't speak for sysadmins. I'm a sysadmin, and I love Systemd.

He may speak for some subset of sysadmin, but he certainly does not speak for us all.

Re: Systemd redux: The end of Linux

#204

Post by rantanplan »

badgersandjam wrote: post #195
nailer wrote: post #186

Earlier quoted context omitted.

I installed CentOS 7, with no prior systemd experience, had no problems and found .service files way neater than sysvinit bash scripts and liked having meaningful names in the log/ journal rather than 'local3'.

I had no problems the second time as well. Unfortunately when the first and second time differ even though identical (recorded) steps were performed, one has to ask the question: why and can I trust it?

Maybe it was a hardware problem on your end?

My rule of thumb is "search for the problem on Google. If nothing comes up, maybe something is wrong on my end".

Did you find any results or reported bugs similar to what you experienced?

Re: Systemd redux: The end of Linux

#205

Post by justincormack »

SwellJoe wrote: post #169
bcantrill wrote: post #145

Earlier quoted context omitted.

You realize that you're just talking in ad hominem circles? You acknowledge that there are reasons that a "reasonable and technically competent person might choose an illumos system"; is it as least possible that someone advocating that choice might not be merely "a random crank on the Internet"? And given that this is potentially a reasonable choice, how does advocating it represent "a very poor grasp of [...] every…

Yes, I find the whole article so full of wrong that I didn't think it needed more than simply calling it "wrong". Though seeing how many upvotes it now has, I guess I was wrong. But, if you insist, let's break it down a bit: "...FreeBSD...also ships with ZFS as part of the kernel and has a jails which is a much more baked technology and implementation than LXC." Which is an assertion that would require significant ci…

It is a terrible article, I think we can all agree.

Its CoreOS point is stunningly ignorant.

However, Zones and Jails are a good substitute for LXC; they are not yet such a good fit for the Docker way of using containers, which is somewhat different. But for a whole system image type model like LXC they are both great.

SmartOS is doint great things with Linux compatibility, both through emulation and KVM, it is worth looking at.

Re: Systemd redux: The end of Linux

#206

Post by badgersandjam »

moron4hire wrote: post #200
badgersandjam wrote: post #193

Earlier quoted context omitted.

That sounds like an excuse which I don't accept. I have a formal engineering background and whilst you're fundamentally right, engineering is based upon cumulative experience gained. We have a hell of a lot of experience as a society of writing software that works and is of merchantable quality. What the general state of affairs shows is the following traits: 1) There is no thought and research going into the design…

Wait, so let me get this straight. You're an engineer-engineer, not a system administrator or a software developer. And you think there is a fundamental problem of qualification in software development, yet you lack qualification in software development. On your points: #1 is patently false, to the point of being extremely insulting. You've lost all sympathy from me at this point. Go peddle your baseless opinions som…

10 years in EE (embedded systems, defense industry), then 15 in what we now call devops/architecture. Experience is fine. I have no problems being arrogant about that. I've fallen down a lot more holes than a lot of people and know what I'm talking about.

When I say tested properly, I mean tested completely. If you miss an entire functional unit of the software and a client reports it as broken, its pretty obvious what the problem is.

Our senior software guys sat down for the other four hours and presented all our findings together and cumulatively said "we're not supporting that shit; we can't trust it".

Regarding #4, it's plain to see that RHEl was released with a broken systemd implementation due to deadline...

Re: Systemd redux: The end of Linux

#207

Post by billybofh »

badgersandjam wrote: post #95
AaronFriel wrote: post #80

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…

I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never l…

I've been a longtime linux sysadmin (back into the 90's) and have run into similar issues as you. I've never had as many problems with basic system stuff as I have since testing some of the new systemd-defaulting distro's. For instance, the centos/rhel 7 boxes I've tried have erratic problems - sometimes not setting the hostname, sometimes services don't start, sometimes services I've disabled _do_ start. It's making me really think about shifting to FreeBSD (or, god help me back to Solaris).

Re: Systemd redux: The end of Linux

#208

Post by justincormack »

why-el wrote: post #188
andolanra wrote: post #24

Earlier quoted context omitted.

It's important to note that the blog post doesn't mean, "Linux is done for," but rather, "Linux is going to be a different kind of system than it has been historically." Some people think this is a good thing, and some think it is not. EDIT: I want to emphasize that I am trying to write this comment neutrally, not endorsing either side, so while my biases may sneak in, my intention is to be fair to both sides. Both s…

I know we don't have access to the OSX code in its entirety, but could one argue that they actually did change how init works in FreeBSD? And perhaps that is one of the reasons the OS is stable? It's not far to assume that the Linux folks are going for more control over init for specifically this reason.

They did change init, but it is not about stability, the main reason was support of hotplug and dynamically adding and removing services. You expect stuff to happen if you plug in a new device and so on, and that is integrated into "init", so it is not so much "init" as an ongoing service that deals with events as they happen.

Re: Systemd redux: The end of Linux

#209

Post by justincormack »

egil wrote: post #94
convivialdingo wrote: post #22

Earlier quoted context omitted.

Well, here's the basic deal. If we're talking about common servers, common desktop, etc then systemd is an excellent replacement. It covers the base of users quite well. But lets say you are building a highly specialized application. You are going to be making quite a few customizations which are far more manageable through a shell scripting environment than by customizing a bunch of binaries. I assume that Redhat is…

The status quo for such projects is to use Busybox, and I reckon it will continue for projects where systemd etc is too much.

There are other options, in particular the Musl libc-based distros like Alpine Linux and Sabotage (where you can use busybox but dont have to). They also feel much more like the traditional BSDs - Musl libc and pkgsrc is very close to a BSD...

Re: Systemd redux: The end of Linux

#210

Post by pdkl95 »

Wow. The UNIX-haters are out in force. Apparently proven, real-world tested code is no longer a relevant feature to a lot of people. Well, "Those who do not understand Unix are condemned to reinvent it, poorly."

But enough about the technical distractions. Why is systemd so important? It's certainly not technical quality or design (even if some of the ideas are useful, the implementation is junk). There is a far more important reason, that some of you have noticed parts of, at least tangentially.

From this very thread: "systemd makes a lot of sense for embedded systems". Yes, it does, andor, and it's all because of this: "kdbus: efficient IPC". The thing is, kdbus/dbus isn't really that great for a lot of things - you have to bounce through the kernel at a minimum, and there is and encode/decode steps that add some overhead. It might be useful for some types of IPC, but it is replacing what should be a fast and simple library call in many places.

Now, here's where a lot of you are going to start calling me crazy or "obviously wrong", both without actually addressing the key claim, which was is probably better explained by stevel over in the Gentoo forums[1]. I encourage reading that post.

The goal with all of this is not technology related at all: the systemd takeover is an attempt to separate Linux and many userspace tools from the GPL, so that software can be used under the LGPL terms instead.

What is the big difference between GPL and LGPL? Linkage. Linking to a GPL library requires you to follow certain requirements if you link against it, while the LGPL specifically allows taht usage. (k)dbus provides the workaround, by replacing what would be a normal function call into a library with a "IPC". It's slower, but so what, computers are way faster than needed. In the end, while you can still choose to release your code as GPL, if you have to use an IPC mechanism to do anything useful the license requirements that will actually apply ends up being being more like the LGPL.

Well, if I wanted to release under the LGPL, I would. What I'm not going to do is undermine my choice of license just because a bunch of embedded developers (and others) want to use what were traditionally GPL projects without having to be bound by the coopyleft requirements. If this was proprietary software, you would call that kind of behavior "stealing".

(seriously, the linked comment below does a much better job of explaining this)

[1] http://forums.gentoo.org/viewtopic-p-7645524.html#7645524

Post reply on HN