EmanueleAina

Right. It sounds infinitely sad too. :(

So the Free Software movement is oppressive because it is trying to change the software culture from proprietary to free?

Very true for low-level system libraries, but applications should really not waste energy on trying to be OOM-safe: it's hard to understand which actions are safe when you no longer can allocate memory (releasing resources often requires allocating memory temporarily), and it just adds complexity which basically will never get tested, thus getting broken quickly and gaining nothing over just crashing on a NULL dereference.

See the experience of the D-Bus (which tries hard to be OOM-safe) on this topic: http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-b...

> having proper distributed service management

Which is more or less what CoreOS's `fleet` already does on top of systemd. They used a different protocol for remote communications (etcd, ie. HTTP+JSON) vs. local, which I guess can be a sensible choice as requirements are quite different.

I guess it's meant to go over TLS, just like HTTP basic auth.

For what is worth, microcommits + rebase for fast-forward merges are the basis of the workflow used in the GNOME project.

As far as I know, it's more or less also what it is used by kernel people before hitting the tree of a maintainer (and it's non-ff merges from there).

True, but for most of us there's more than just groups and users. su is helpful to add other users' privileges to the current session, but there was no command to create a new full, isolated session other than logging in on a different tty or ssh'ing to localhost.

`machinectl shell` now implement that feature, with the added bonus of being transparently able to log into a local container (or possibly even virtual machines).

To some extents, it depends on the definition of C: by the standard, you're right, you can't. But with some relatively common (GCC and clang) extension (ie. __attribute__((cleanup))) you definitely can, see g_autoptr() from GLib for an easy way to use it: https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/

Honest question: is NixOS really doing reproducible builds, where you get byte-identical binaries when rebuilding from source?

I only found this issue on the Tor tracker, and apparently NixOS does not produce reproducible builds in the same way as intended by Debian: https://trac.torproject.org/projects/tor/ticket/12520

I don't think so. Reproducible builds means that compiling the binary packages results in byte-by-byte identical copies, even when done on different machines at different times: the packaging sources do not get any simpler (to the contrary, they may get slightly more complex due to additional concerns).

The XDG App effort to produce standardized runtimes and isolated applications is probably what you're looking for, but it is completely orthogonal to reproducible builds as runtimes for XDG App can be built in a multitude of ways, eg. with pre-built distribution packages (reproducible or not).

I guess once the negotiations have ended, the full text will be available on the EU website, as many position statements already are. After that, many national governments will have to vote on it, and I guess you can consider those public acts too. I guess that's as much public as you can get, short of printing it up on every available wall.

You either don't know the meaning of the word "irony" or you have some issues with cause→effect relations.

If you talk about cabals, there's no point in having a sensible discussion. Te existence of secret cabals is a matter of faith, and you cannot really discuss things of faith with reason alone.

In any case, both GNOME and Debian willingly adopted systemd. Thinking otherwise implies that GNOME and Debian developers are silly idiots: it that's the case, why bother. If it's not the case, they know what they want and nobody forcecully "pushed" anything.

The vast majority of third parties GTK+2 themes were using the pixmap engine (or murrine in some cases), which was basically what the current CSS engine is, just more arcane and infinitely less flexible.

I reiterate: full stability for theme developers CANNOT be provided, unless you're willing to give away much of the power of the current theming system, basically going back to the annoyingly limited pixmap engine. This (understandably) is not a tradeoff the GTK+ developers are willing to make, and I guess neither third party developers.

> Meantime, clunky, terrible C modules written back when GTK 2.10 was a thing work just fine on 2.99.

I don't know, I remember Murrine being often broken after new GTK+ releases, despite it being under active development.

> https://github.com/shimmerproject/Numix/issues/206

That issue has been opened on 10th April, I guess your issue is more than your theme needs more help for its maintenance rather than GTK+'s fault. Again: there's no provision of stability for themes. Either you accept to keep up with upstream or you'd better stick to the default theme. Just like using a greasemonkey script when a website changes.

The changes in GTK+ have become progressively less dramatic: this means that fixes for themes are now smaller/simpler, not that they don't need active upstream tracking.

> imperative chunk of simple and straightforward C is far better than arcane declarative CSS based

Nope, consider yourself lucky if you have never heard the horror stories about the old theming code (and even more lucky from the fact that you never had to poke at it). :)

P.S. Me too, I worked at a small studio developing web apps for a few year, then moved to optimizing HTML/JS/CSS3 apps running on a custom WebKit enviroment with animations, transitions and whatnot on a embedded (and horribly low-powered) platform and now I have the pleasure of trying to make WebKit work well on the Raspberry Pi.

As far as I can tell, CSS is several orders of magnitude better than poking at C code for those purposes.

> pushed to RHEL and Fedora

It's more like systemd was developed for Fedora/RHEL, given that a good chunk of its developers are from Red Hat.

Also, I doubt that the Fedora/RHEL maintainers are a bunch of loons easily fooled by systemd developers, so I guess they willing adopted it and nothing has been pushed. If instead they are the loons you seem to imply, I wouldn't care much about their decisions.

> Debian lacks strong leadership with vision, and so they simply did what they always do which is to blindly follow RedHat's lead

Ah ah ah, no. Please go re-read https://bugs.debian.org/727708

No revisionism here:

1) in no possible way "I'd like to propose systemd" can be seen as forcefully "pushing" something

2) please go read (or re-read) the full discussion behind the Debian tech-ctte decision[1] to understand how little the GNOME dependency mattered

[1] https://bugs.debian.org/727708

Nope, that's not really the same thing.

> * sysv removed http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1...

> We have won. Now remove all remains of our defeated enemy as fast as we can. As said in the beginning of the systemd crusade against the UNIX infidels: »You can patch it out.« It is no more there.

Are we really complaining that LSB script support has been moved out of PID1 to a separate binary? Wasn't one of the major point for critics that systemd has too much in PID1?

I'm not sure I understand your comment. Are you proposing to move all the systemd features in the kernel? Why do you think it would be a good idea.

Note that one of the stated goals for systemd is to make good use of all the new fancy features are already available in the Linux kernel but not many people use because they are not portable (eg. control groups). Also note that some cool features have already been merged in the Linux the kernel after the systemd developers created them (eg. memfd).

RedHat and Samsung open source contributions aren't really comparable, despite the latter having got much better lately. Despite me being a long time Debian user, I've always appreciated how RedHat employees have always been community members first and RH employees second.

Note that systemd was not pushed to anything: several members of the various open source communities appreciated their features and considered it worth to be used and even made the default. Please read the long, technical and detailed discussion Debian had before choosing systemd as their default init system while still providing sysvinit as a supported choice: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

Also Intel developers didn't design GNOME 3 for touch screens. Sure, Clutter development was at some point carried on by Intel, but most of the GNOME design comes from RedHat and volunteers. That said, it's true that GNOME cares for keyboard, mouse and touch interaction: and I'm very happy that they care about touch, thanks to them using the touchscreen on my new laptop has been a pleasure.

To answer your concerns, both systemd and GNOME see a big investment from RedHat in their development, but the developers are influencing RedHat's choices more than the opposite. Keep also in mind that a huge number of contributions still comes from non-RedHat developers for both systemd and GNOME, at the moment there's no risk that the company will drag these projects where their maintainers don't want to go.

It's not a matter or "impressions" but rather the matter of chance: when a vulnerability is published you may have the chance to fix it before someone figures how to use it in a exploit.

If the exploit is released immediately, that chance becomes effectively nil.

Of course this doesn't change the fact that everybody should apply the patch ASAP, but delaying the exploit simply adds some delay to the bad guys.

> May be I am wrong, but theming engine is a vital part of an UI toolkit

Arguably, for a big chunk of GTK+ users (me included) it's not. I care about the work on the default theme as I can't really be bothered to install custom themes. For me, the same is true for Qt or whatever other toolkit: either they give me appropriate defaults or I will probably tend to ignore them.

That said, it seems that GTK+ developers agree with you more than you seem to expect: in the past few cycles they worked a lot on the theming engine, simplifying it to the point that the whole theme is defined only by CSS.

Instead of writing clunky, complex loadable modules in C, they can just mash together some CSS and customize every part of the UI. This is a massive improvement over GTK+2.

Of course, since the CSS can poke at the deep internals of the toolkit, complete stability cannot be provided: think of it as a user-level CSS that cannot cleanly cope when the target website changes.

Things have improved a lot with the CSS engine maturing. With GTK+2 themes where loadable compiled modules and where far from simple.

With GTK+3 you do everything with CSS alone.

Of course full stability cannot be provided due to the fact that the CSS can poke at the internal composition of composite widgets, not unlike how greasemonkey scripts can hardly cope with the target website changing, but things got much more stable in the last few cycles.

No need to SHOUT to convey your message.

Indeed, I wasn't really trying to quote the article when I was talking about height, I just took a bad analogy on my own (certainly influenced by what I just read, but that's not the point). Sorry for the confusion.

> Men and women, on average, differ significantly

The linked article explicitly does not take any stance on that. What the article points out is that males are more extreme in their traits, eg. exceptionally tall or exceptionally short, which in no way means that there are average differences. Even if the deviation is different, the mean may be the same.

Not that I'm saying that those differences are or are not there, but to say that the current differences are entirely due to biological differences would seem a bit naive to me.

> the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false

Indeed, I agree with that. The only advantage is that the restricted syntax of unit files is more suitable for error checking rather than having the shell complain more or less randomly, but compactness is not an intrinsic advantage of it.

That said, not every distribution standardized on such kind of helpers (ie. Debian), so in those cases compactness was one of the benefits of switching to systemd (not exclusive to it).

The few times I tried to run GUI programs through su I always got plenty of warning about DBus and stuff. But I don't do that very often, so that's all I know.

> What userspace programs interpret the quiet parameter? > Genuine question. AFAIK, quiet does (or should do) nothing other than disable some of the kernel logging.

At least plymouth and probably every init system out there.

Linus said that "we very much expose /proc/cmdline for a reason. System services are supposed to parse it, because it gives a unified way for people to pass in various flags. [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature."

http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html

> The bug report makes it immediately clear that this is not really about a technical problem that ought to be solved - no, the dirty user-space programmers should get their stinking paws off of our good kernel command line flags, how dare they!

You're right that Kay was wrong to close the bug immediately instead of trying to help finding the real cause, and you're wrong when you say that userspace should not parse the kernel command line, see Linus' remark above.

> There's no reason to even assume procfs will always be there

To the contrary, dropping it would be an ABI break so it's really safe to assume that it will be always be there.

> who's been programming for more than an year

Please, don't lecture others about their job. I'm not assuming you're an incompetent fool, please don't assume I am.

> if a program did that on Windows

And can we try to stay relatively on topic? Windows is definitely unrelated.

(I'm not otherwise replying in detail because you assumed that parsing the kernel command line was not ok, while Linus officially blessed its usage. Also we reached the max thread depth on HN, which should probably suggest something.)