zxzax

I don't get it, that seems like standard fare for an R-rated movie? And then it seems like some complained because they decided to start editing it down to a PG-13 movie?

How does that even work in practice? Does the team have to ship a bunch of successful Switch and Xbox games first before their resumes are viewed as good enough? And it seems like they would have to plan to ship the project under development on one of those other consoles, just in case they don't get approved?

It seems they don't necessarily have to be using a cloud-based service to sell/leak phone numbers to a third party?

I'm not sure I understand what your opinion actually is? What you've stated is a fact, not an opinion: that's what the web platform is now. So it really makes no sense to rant about that, in context. You say you won't be advising him of that, but you also seem to be arguing in favor of advising him of that, not against, and are in fact already somewhat doing it already, so it's not clear what you meant there. It may benefit to be more consistent here, and make the advice to him anyway.

What would make more sense, and be more valuable, would be to talk about what value was actually taken away, and what steps could be done to provide that value again, without taking other bits of value away in the process. The blog post, as it's written, only argues for taking more value away. So I didn't find it convincing towards that end, and it seems you didn't either, as per your GP comment. So I'm pretty confused by this follow up response.

Please don't shoot the messenger here, but your doctor and insurance company are very likely already using the web to exchange information about you. You can either have that in a way that is standards-complaint and vetted by a large group of browser engineers, or they could try to roll their own... which would you prefer?

You might consider advising your friend to shy away from the "rant" and "hot take" styles, I know it's popular among bloggers and twitter users but it's pretty uninteresting reading for someone who's read this type of post about web browsers for what feels like the 1000th time... If it was feasible from a technical and business standpoint for the chromium team to cut costs and remove 95% of the features added in the last 5-10 years, they would have done it by now!

>"Port scan crashes machine" is not exactly "reliable software". [...] So you agree that it's a bad idea? [...] But that means that the default is bad, and unsuitable for resource constrained machines.

I'm not sure I understand where you're coming from here? I explained how it could be made suitable, it could be done in a way that was crash resistant. I don't know if it's a bad idea or not, it depends on what you're trying to accomplish. The default here is configured by the distro, so you could expect to see a different default on an embedded distro.

>In fact my Ubuntu default install doesn't even have inetd installed.

I believe this is mostly because systemd has replaced its functionality.

>netstat has supported this for (maybe) decades on Linux. It's the -p option.

Good call, I forgot about that, I always use lsof. But that's exactly what I mean, it will show you which pid has the port open, so it will make it obvious if it's systemd or sshd. You won't be sure if there is actually an sshd running unless you check that. This really seems like a non-issue, you have all the tools you need to troubleshoot it.

>systemd broke this functionality. [...] Port is closed means service not running. [...] Pre systemd it was essentially never anything other than inetd that held ports for others.

I don't really want to discuss this anymore if I have to repeat myself, but this is not correct. There are multiple other reasons why you would have another service holding the fd open, such as load balancers, filtering proxies, userspace firewalls, etc, etc. The ability to pass an fd to a child process is an intentional feature of every Unix-like operating system that I've used. Systemd is only using the feature as the OS intended it, which is also supported on OpenBSD.

Sorry I think I missed that. In that case you will have to find someone else who can do it and figure out how to get them paid. If you want help doing that, don't hesitate to ask.

I ask the same question because I haven't yet seen a better alternative that was given. If you have one, please show it, it would be very interesting to me. Otherwise, it sounds like you may not have that much experience with these tools, which is understandable. I can help find solutions, if you're interested.

>Does that mean that I can DoS these machines simply by connecting to all the open ports, thus starting up the heavy daemons in the constrained environment?

I'm not sure I'm understanding this question? A lot of machines are not open to the public internet, so this probably doesn't apply there. You can also use some cgroup managing tool (like systemd) to restrict memory usage to the process and configure the OOM killer behavior, so that would also prevent DoS attacks.

> Yes, actually, netstat will show you if you have an HTTPS server running. It will show you if you have an SSH server running.

Actually no, this is wrong, at least for me when I tried the version of netstat that ships with debian. It only shows if something has the port open -- that thing could be an fd holding service (like inted or systemd or something else), or it could be a load balancer, or it could be another service that is incorrectly configured to use the wrong port, etc. So you're right that this complicates the system but this isn't really systemd's fault, and there is nothing that a service manager can really do about this. The only way to know for sure is to use a different tool that prints information about the owning process -- that way you know for sure if it's sshd or something else. Maybe you have a version of netstat that shows this information? If so, then it's not a problem at all, just simply check that column before you continue with your trouble shooting.

>Will it tell you if you're actually running SSH on port 443? No, of course not.

Well now you got me confused, this seems to be directly conflicting with when you said this: "It will show you if you have an SSH server running"

It can also be about initial startup time of the system, not startup time of any individual service. Please follow the site guidelines, c.f. the part about "don't cross-examine" -- this is just a technical tool, I'm sure we both can come up with some ways that it could be useful, even if we wouldn't use them ourselves.

>But systemd needs a few full time adults, not just a patch here and there to fix the launch-while-brainstorming culture that gave us the current situation.

Then start working it on it full time, and get some of your friends hired too? Surely you can find someone to pay for that, if it's useful? What else is it that would satisfy you here? I'd be happy if another group was committing full time to systemd (or another similar open source project) just to fix bugs. I fully support you if you decide to do that.

If you have suggestions on how to fix that I think a lot of people would love to hear it, but for now, sadly the task of building a fully complete desktop and application platform means that there is a lot of code and a lot of churn. This is true of every single major platform.

Not really, you just happened to pick two projects that are particularly large and particularly old. Drive-by commits are a lot less valuable in those type of projects, unfortunately, but you can still find places to contribute if you spend the time to look.

>But it's broken by design. It's a bad idea.

You keep saying this, without giving evidence to back it up. People are still running Linux in memory constrained environments, those didn't go away now that the 90s are over.

>Using this feature pushes orders of magnitude of complexity onto users, and greatly reduces the ability to error handle or even know the status of services.

To be clear, it sounds like what you're suggesting is that these services implement their own fd holding logic, which is going to be even more complex, and is exactly what systemd is trying to prevent from happening.

>You check if the service is turned on (systemctl or whatever), you check if the process is running (ps, etc), and you check listening ports (netstat, nmap, etc...), they all agree that the service either is or isn't running. And if it's running, it's successfully run its initialization and should be usable.

This isn't really correct, netstat or nmap won't show process status at all. You really don't know what the real status of that port is unless you've run lsof or something else that scans the open fds of the processes, and such a tool would make it obvious when systemd (or some other fd holder) has the fd open. Also, systemctl will display this separate socket/service units, so you can just check if the socket unit is running but not the service.

If you think the socket activation takes too long you can just turn it off and start that service unconditionally. What's the problem? Other service managers support this too, it's not a systemd only thing. Maybe it's a bad idea for some services but others would seemingly disagree that it's always a terrible idea, and not just those who are systemd developers. You may just be using it for the wrong services -- it's most useful with services where the startup time is less important than reducing the overall memory usage on the system.

If you have experience making software reliable, please consider submitting bug reports and patches to help the project, like you would do with any other open source that you depend on. I'm sure contributions to improve the testing and CI would be appreciated. A high school student can also trash talk loudly about things they didn't take the time to fully understand (and I admit I did a lot of that when I was a teenager in high school), but it takes real expertise to illustrate what the actual problem is and to contribute a fix for it in a positive way.

I just use systemd and pipewire, it's not a problem for me personally. They're the worst options... except for all the others :)

To me it's the other way around -- pipewire is the sound server equivalent of systemd. For better or for worse.

This is incredibly saddening news, near was an active HN user whose posts I always enjoyed reading. These cyber stalking websites needed to be shut down long ago.

You can just use podman to run Docker containers. That workflow is honestly what I wanted years ago when I first used docker, where containerization is put in the core system, and you can progressively add containerization to your core services while also running a full container on top of the same runtime.

Sure, but that's entirely the problem those centralized logging services were made to solve. You make it really easy for everyone in the company to put their logs in the right place.

That's not a full picture, apparently that was due to some specific problem in Gentoo: https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

AFAIK the GNOME Wayland session still depends on logind, but that's more because there has been no interest in getting it to work on BSD yet.

>They are not removing deprecated things, whenever possible the old things are still around and call the new things.

That's great that they have the bandwidth to do that, I commend them for it, but other projects don't have the time to maintain and work around deprecated APIs forever.

>Lazarus' currently main backend for Linux is GTK2 exactly because the Gtk developers broke backwards compatibility with GTK3.

If they want to help avoid this in the future for other programs, I would urge them to try to write some kind of compatibility wrapper. It would mostly the same amount of work as doing it upstream, and upstream seems to have no interest in doing it since they would rather focus on helping people get their apps ported to the new way. But this would only work for some things, other things simply can't be provided with any amount of backwards compatibility.

>That is the point, it isn't easy or profitable. But something being not easy nor profitable doesn't make it wrong. After all the entire CADT thing is about focusing on the easy stuff because that is fun.

If you take that approach, you really could say the same thing about these other projects that don't want to upgrade their apps to GTK3/4, etc. Of course they won't do it because it's not fun for them, those projects don't really care about the toolkit, they just want to have some kind of GUI quickly so they can then focus on the rest of their program. At least that's been my experience with them anyway, I sympathize with that but it also conflicts with the need to make changes in the toolkit. So eventually somebody has to compromise somewhere.

>JWZ's page is very short and amusing to read, i recommend reading it.

I've read that page more than a decade ago, as I've said I think it's condescending flame bait that serves to distract from the real technical issues. And it's ableist towards people who do actually suffer from attention deficit disorders. If you want to help fix these issue, please don't refer to it.

>By causing it to become "overly complex and burdensome". To avoid the hard work on 2-3 developers this approach pushes that hard work to 20000-3000000 developers.

I'm sorry I really don't understand what you're saying here. The 20000-300000 developers should easily be able to join together and use their numbers to come up with a solution that is much better for them, no?

>Which they shouldn't have done.

I would urge you to try to maintain all those system libraries for a few years, and then revisit this statement and see how you feel about it after that.

>But they should, or at least they should wrap these APIs so that they call new stuff

Somebody interested in this can just build this wrapper separately, there's no reason it needs to live in the same repo as the new version.

>I have a feeling you are greatly underestimating the combined effort that went on FPC and LCL.

Not quite: my point is to illustrate that the samme amount of work needs to be done in other projects if you want that level of backwards compatibility.

>Key words: "worth it". Worth it to whom? People who want to play on shiny toys?

If you want to describe new features, improved performance, security fixes, etc, as "shiny new toys" then yes, I guess you could say that. I'm not sure what the distinction here is because before you said you wanted these shiny new features?

>The problem is if they break things intentionally. THOSE are unavoidable.

That's also the point I'm getting at: Xorg was at a point where they were going to have to break things intentionally, because some of those APIs are actively causing security issues and cannot be fixed without unavoidable breakage. The apps have to move to a new API if they want this to be fixed, there is no way around it. Any rootless X server (such as the one you used on Windows) will also cause some apps to not work in subtle ways, compatibility is not perfect there either, and Xwayland is basically built with the same design constraints.

>Or even GIMP, which took ages to switch to GTK3 (again, just in time so they can now waste even more time to switch to GTK4).

Depending on your project, porting to GTK4 won't be a waste of time. The rendering model has changed entirely and is now mostly hardware accelerated, so you may see major performance improvements on e.g. high DPI displays. But this is not something that can be provided by a wrapper, to get the major benefits out of it, the apps have to rewrite their widgets to use the scene graph instead of using old-style immediate mode drawing. There would be little benefit if you didn't do that and continued to use GTK2-style drawing. For me at least, that's why I think it's mostly a bad idea to try to make a complete compatibility layer. Maybe it would work for some widgets but apps really need to do a real port if they want the major benefits.

In some ways yes, in other ways no. I've looked at both, and there is always a certain amount of "ugliness" that comes with writing low level C software for Unix.

>is a scourge on open source

I wouldn't say so, unstructured complaining really doesn't help at all. If the project has been around for a while then the flaws are usually well known. Before you lodge a complaint, you'll want to check the bug tracker to see if something has already been discussed. If it has, then the flaws have already been pointed out, and further complaining upon that point does nothing and only serves to annoy the people working on a fix -- the best thing to do there is to start contributing and collaborating on a fix to the issue. Then once you do that, you'll see why it's not helpful when people keep bothering you with "is it fixed yet" type comments :)

The D-Bus RPC is considered deprecated in favor of Ice and can be compiled out.

It's not a bad idea, but that essentially means running a dynamic DNS service (or partnering with one) which is outside the scope of mumble.

Ok so complain to the ops department that they need to unify their logs. That's their problem, not yours. If the company is big I would expect them to be doing that anyway, either they coalesce around a journald-type thing that aggregates the logs locally, or they'll use another centralized service like datadog, splunk, etc. Edit: If you are ops then this is your entire wheelhouse, you should be able to solve it at scale without messing everything up.

You can just disable the fd passing for services that don't need it. I'm not sure what your actual issue is. I haven't had to reboot any more with systemd than I did with sysvinit or openrc, or the slackware rc init, or anything else really. If you have an actual crash that is causing you problems, you should consider reporting it or submitting a patch to fix it, just like you would with any other open source that you depend on.

>systemd is on the level of a re-think by a pretty bright high school student.

That seems like an odd statement, I believe systemd was inspired by other established unix service managers like macOS launchd and solaris SMF. The design is definitely not perfect but I wouldn't say the history was ignored when making it.

I'm not sure what period you're alluding to, but if that did happen, it seems it happened because things stalled on the BSD side, not because of any changes in GNOME. Can you please elaborate what you mean? I'm interested to get a BSD developer's view of the history, but I've only seen a few vague blog posts on this matter.

I honestly would like to see a better service manager than systemd, but just my opinion from following development of these things: a huge reason why it can't happen comes from underlying deficiencies in the kernel, and with Unix. The real core issues can't be addressed without a large amount of changes there, which are outside the control of a service manager.

I generally agree with the comments in the research paper about clone + vfork, most applications seem to not use it at all (either directly or indirectly through posix_spawn) for those reasons.