Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
EmanueleAina
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
EmanueleAina
11y ago
> Except that rc.subr is shell scripting alone. Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it. My point is that ei
62.
▲
by
EmanueleAina
11y ago
> the systemd folks assumed that they were the center of the universe and decided "well fuck the kernel, we're going to use the 'debug' flag for ourselves, everything else be damned" Note that even Linus said tha
63.
▲
by
EmanueleAina
11y ago
Interesting read, thanks! However I would not characterize that as "Poettering completely misunderstanding a perfectly valid use of su". It seems a quite complex issue about a workflow that is only half-working even without system
64.
▲
by
EmanueleAina
11y ago
> It's a parameter passed to the kernel. Just like "quiet", which is totally meant to affect userspace programs. > It's a ridiculous clunky hack that stinks of large company coding practice: what they actually nee
65.
▲
by
EmanueleAina
11y ago
Yep, my point is that knowing shell scripting alone is no longer enough and it's not different than running `man systemd.service`, only that you're keeping the weirdness of the shell language just to set a couple of variables.
66.
▲
by
EmanueleAina
11y ago
Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer. My personal opinion is that having a s
67.
▲
by
EmanueleAina
11y ago
I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable. And "look at the source" is a sad answer, no matter if the source is a shell script or C program. The point is that with
68.
▲
by
EmanueleAina
11y ago
> A -> B -> C -> D. Easy. Oh, sure, sequentially starting up a fixed list of services is probably easier with sysvinit, given that's the only thing it does. With systemd you probably want to set Requires=foo and After=foo i
69.
▲
by
EmanueleAina
11y ago
Honestly I find that a single global "debug" option would have been useful, instead of having to know which component (the kernel, the ramdisk, sysvinit, sysv-rc, systemd, upstart, udev, whatever) is at fault. Unfortunately such m
70.
▲
by
EmanueleAina
11y ago
It worked before, it stopped after a change in the kernel, another change made the problem disappear: the root of the problem was definitely a bug in the kernel. That said, it's perfectly fine for the kernel developers to clarify that
71.
▲
by
EmanueleAina
11y ago
Never heard about it, is there any link with more details?
72.
▲
by
EmanueleAina
11y ago
> Complex needs are better solved with source code rather than special blobs of $system. Arguably, reinventing multiple complex wheels is often a not particularly good choice. So either you're implementing something really novel in
73.
▲
by
EmanueleAina
11y ago
Are you seriously saying that most distribution maintainers were happy with sysvinit? For what is worth, all the Debian maintainers I know, even those who are not systemd supporters, felt that sysvinit had to go in a way or the other (eg. d
74.
▲
by
EmanueleAina
11y ago
Why is resolved feature-creep? It's rather nice to have working name resolution out of the box when coupling it with networkd and firing up a container. I mean, it's not my standard usecase in this moment of my life, but I see how
75.
▲
by
EmanueleAina
11y ago
The per-unit cgroup and the ability to kill it is rather nice too, without delving in the container-related features where the systemd server-side support really shines.
76.
▲
by
EmanueleAina
11y ago
Many systemd features are explicitly tailored for server workload (eg. resource management), and a particular effort is being put over container-based deployments. CoreOS has been quite successful in basing their own infrastructure on syste
77.
▲
by
EmanueleAina
11y ago
> My deadline for almost all work I do is "yesterday". Having more or less worn both hats, it's exactly the same for developers. :)
78.
▲
by
EmanueleAina
11y ago
> but software developers tend to forget that software is just a tool, and sysadmins use it like a tool. They just want to get in, get out, and move on to the next problem Which is exactly why developers don't get to write any docum
79.
▲
by
EmanueleAina
11y ago
If your needs are simple, the resulting unit file is trivial and you can basically copy and paste from any example without looking at any documentation. If your needs are complex, you have better chance by mixing different options in the co
80.
▲
by
EmanueleAina
11y ago
Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple app
81.
▲
by
EmanueleAina
11y ago
> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files How that's different from sysvinit? > The
82.
▲
by
EmanueleAina
11y ago
Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial synta
83.
▲
by
EmanueleAina
11y ago
You can still use plain shell-based LSB-compliant init scripts just fine, which is what Debian is still doing as they didn't want to have flag days like all the other distributions who switched. I don't see why you should feel hom
84.
▲
by
EmanueleAina
11y ago
I don't think it's really fair to compare writing unit files to being able to program in shell. True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-ins
85.
▲
by
EmanueleAina
11y ago
As I see it, unless you can guarantee that you give zero false positives (which, knowing how certain users compose their mail, is arguably impossible) you still have to do it. Also I suppose that the false positive/negative rate can on
86.
▲
by
EmanueleAina
11y ago
Again, I never assumed that because somebody is interested in a woman they just want her body. To the contrary, I have no reason to believe it, and I assume we're discussion honest interest here. > Who would it be OK for an investor
87.
▲
by
EmanueleAina
11y ago
People get called unfunny names regardless they actually have sex with someone. And no, I'm not assuming that men are incapable of being genuinely interested in a woman. To the contrary, I have no reason to think otherwise. It's j
88.
▲
by
EmanueleAina
11y ago
I already mentioned some of relevant points in the comment you replied to: 1) compartimentalized, not a big, global dumping ground 2) same builders network as unstable/testing 3) no need for a reupload to push to unstable/testing
89.
▲
by
EmanueleAina
11y ago
Qt, LibreOffice, OpenStack, Linux itself, WebKit, GStreamer, Wayland just to name a few have both paid and freetime contributions (often from the same people too). Neil works for Collabora, we contribute to quite a few projects in our paid
90.
▲
by
EmanueleAina
11y ago
The plan for Debian PPAs is for them to be quite different than the ones from Ubuntu, they will be available only for those that already have upload privileges. They will be a sort of compartimentalized experimental, with no different build
More ›