Live data from Hacker News

Mir’s next steps – we need your input

community.ubuntu.com

41–48 of 48 posts

Re: Mir’s next steps – we need your input

#41
post #38

Earlier quoted context omitted.

Systemd is one of these things that brings many improvements... and gets talked down. If it was at least criticized constructively, but no, it is something else than the "traditional" init, so let's just berate it. And then we wonder, why the Linux desktop is always out of reach, when we dismiss anything, that helps to drag Linux out of the maze of one-off bash and perl scripts.

No. I’m no init fanboy, I’d have just adopted Apple’s launchd and called it a day. No, criticisms of systemd are plenty and well argumented, and yet get systematically talked down. First that comes to mind is the cavalier reaction to leaving some firmware fs mounted rw because systemd used it during reboot; didn’t matter uncautios mishaps could brick a device, team just won’t-fix’d the report and called everyone else…

Apple launchd is way more limited, and has much narrower scope (single-seated, single-session desktop). We could talk days about features that systemd provides and launchd doesn't.

I've seen only single case of criticism of systemd that was correct and constructive (too bad I didn't bookmark it); I don't count rants that boil down to "it's different than I'm used to", or "it has broken my broken nfs config" as plenty or well argumented.

The efi issue was indeed a bug in the devices. If was up to the manufacturer to fix it, not for other software to maintain workarounds indefinitely.

Re: Mir’s next steps – we need your input

#42
post #20

Earlier quoted context omitted.

> Malls or touchscreens that display info and you can interact. Why would that require anything new? I mean, Canonical is in the server OS business mostly, right?

If you have a terminal that needs to run just 1 app then why use Gnome or other DE? you would need to run a minimal display server and start that only application.

We run a kiosk thing, use i3 without a status bar, directly launch the program from the xinitrc (or whatever script, which launches i3 in the background, sleeps 1 second, then launches the kiosk thing), and all this via startx.

If the script exits, X exits, systemd restarts it. Works pretty well.

Re: Mir’s next steps – we need your input

#43
post #38

Earlier quoted context omitted.

No. I’m no init fanboy, I’d have just adopted Apple’s launchd and called it a day. No, criticisms of systemd are plenty and well argumented, and yet get systematically talked down. First that comes to mind is the cavalier reaction to leaving some firmware fs mounted rw because systemd used it during reboot; didn’t matter uncautios mishaps could brick a device, team just won’t-fix’d the report and called everyone else…

Apple launchd is way more limited, and has much narrower scope (single-seated, single-session desktop). We could talk days about features that systemd provides and launchd doesn't. I've seen only single case of criticism of systemd that was correct and constructive (too bad I didn't bookmark it); I don't count rants that boil down to "it's different than I'm used to", or "it has broken my broken nfs config" as plenty…

“way more limited” is a feature not a bug! Eventually Systemd will grow a binary configuration registry, but by then people won’t see the irony of it any more

Re: Mir’s next steps – we need your input

#44
post #10

So X was horrible, because it is very old and blablabla, and Wayland the protocol got finalized without an actual implementation that people use in good old design by committee fashion (no?), and for some reason now everybody writes compositors instead of writing one for Linux in general... I don't really understand why, can someone explain? (I mean, I know about how Mir seemed to be regular Canonical NIH symptom, bu…

> So X was horrible Was it? I feel like someday someone is going to say something like "Man our VR world syncing protocol is really heavy, and we end up needing AGI-level LOD prediction to do it well, but compressing 360 degree light fields is wasteful and leads to latency artifacts... what if there was a protocol that allowed realities to render display-space fields directly to remote devices, but do the final compo…

Sure, then let's do that.

I mean X as a client server visual/graphical terminal solution is pretty amazing.

But then it took more than a decade to get to the point where it seems that DRI extension is just not going to cut it.

And all the other built-in un-security has to go too.

Re: Mir’s next steps – we need your input

#45
post #18

Earlier quoted context omitted.

I tried it. It .. does nothing. Maybe there are/were reference implementations for the protocol extensions too?

What do you mean by "nothing"? Weston includes a usable desktop shell by default. Without virtual desktops, but with a panel.

Case in point, there was no exit. I had to switch linux terminals and kill the process, because even though I was able to launch the terminal (let's say xterm), but I had no idea how to stop the weston session.

Re: Mir’s next steps – we need your input

#46
post #43

Earlier quoted context omitted.

Apple launchd is way more limited, and has much narrower scope (single-seated, single-session desktop). We could talk days about features that systemd provides and launchd doesn't. I've seen only single case of criticism of systemd that was correct and constructive (too bad I didn't bookmark it); I don't count rants that boil down to "it's different than I'm used to", or "it has broken my broken nfs config" as plenty…

“way more limited” is a feature not a bug! Eventually Systemd will grow a binary configuration registry, but by then people won’t see the irony of it any more

It s a bug, not a feature. I like how systemd can reliably track even double-forked processes, or how can I override only tiny parts of the unit definition, without having to rewrite the entire unit and thus the original definition is still updatable by upstream packages. Or how it can inform me, in what state either the given unit or the entire system is, including last few lines from the log. Or that there is unified system for unit activation no matter how they are activated (on startup, on socket, on timer, on demand by dbus, etc). Or that it can properly solve dependencies among services, and miriad of similar, small things, that together make a huge qualitative difference.

Ironically from your snark, systemd uses simple ini files. Launchd uses a specially bloated xml, because plists.

Re: Mir’s next steps – we need your input

#47
post #43

Earlier quoted context omitted.

“way more limited” is a feature not a bug! Eventually Systemd will grow a binary configuration registry, but by then people won’t see the irony of it any more

It s a bug, not a feature. I like how systemd can reliably track even double-forked processes, or how can I override only tiny parts of the unit definition, without having to rewrite the entire unit and thus the original definition is still updatable by upstream packages. Or how it can inform me, in what state either the given unit or the entire system is, including last few lines from the log. Or that there is unifi…

We grew up with different UNIX philosophies in mind. IMHO, even Launchd’s cron+init+inetd was a stretch, you’re cool with a second OS sandwiched between kernel and user. Have fun

Re: Mir’s next steps – we need your input

#48
post #45

Earlier quoted context omitted.

What do you mean by "nothing"? Weston includes a usable desktop shell by default. Without virtual desktops, but with a panel.

Case in point, there was no exit. I had to switch linux terminals and kill the process, because even though I was able to launch the terminal (let's say xterm), but I had no idea how to stop the weston session.

Looks like it's Ctrl-Alt-Backspace. I personally never use exit features though, I always switch to the terminal I launched the session from and press Ctrl-C.
Post reply on HN