Threads for PhantomZorba

But since outside of extremely constrained environments we only have 3 OS kernels on the planet (we can probably ignore anything that isn’t NT, Linux, or BSD), we end up trying to use them for more than what they’re actually good for.

Keep in mind that Windows doesn’t do overcommit. We don’t have to go and look at a hypothetical alternate universe of non-UNIX things to see what systems without overcommit look like, there’s a real non-UNIX world without overcommit right there. And it’s absolutely awful to work with.

It would likely require technical error messages like “Sorry, Discord required more memory than the system could spare (currently 300MB). (Note: you currently have 63 programs running, total available RAM is 8GiB)”. I don’t know how someone used to “Oops, something unexpected happened” would react though.

Most early ’90s operating systems would give errors like that. RiscOS had a nice GUI for dynamically configuring the memory available to different things. Oh, the fun we had making sure that the lines were just long enough that programs could launch.

NT just reports failure in VirtualAlloc and that’s typically propagated as an SEH exception. And then a program crashes with an out-of-memory error. And then you look at Task Manager and see that you have 60 GiB of RAM free and go ‘huh?’.

The only reason systems with OOM killers seem to work is because the systems are usually so over provisioned with RAM that they never actually operate in an overcommitted state. This makes these systems a ticking time bomb.

Meanwhile, on the Windows desktop I used at Microsoft (which didn’t have overcommit), allocations would start to fail when memory usage was at 60% and programs would crash with unhandled exceptions from allocation failures.

This isn’t some hypothetical alternate reality, the most popular desktop operating system does the opposite thing and it doesn’t work well at all.

Wholesale ignoring of these course grained memory exhaustion errors is tolerated because software malfunctioning in non mission critical contexts in general is tolerated as long as it doesn’t happen too often.

And that’s how you build reliable systems. Software cannot be 100% reliable because computers cannot be 100% reliable.

From a pure system design standpoint, admitting overcommit and OOM killing changes the process abstraction in a substantial way. Now you must account for your program dying randomly through no fault of its own if you want your program to be correct

As you must for any non-trivial program even without overcommit. Unless your program is 100% bug free (including all of its dependencies) it will crash at some point. Again, you build reliable systems by letting things fail and recover.

Apple systems handle memory very well because the kernel supports Sudden Termination. Processes advertise that they are at a point where they have no unsaved data and so can be killed with no cleanup. This lets them use memory far more efficiently than Windows.

Considering what David C wrote in other comments regarding the challenges of handling memory failures with fine granularity – would it not then make sense to try to make improvements at the application level? Can Drupal/the application be rewritten to become less memory-hungry? If that’s not practical or takes too long time, then memory is relatively cheap these days – one could also increase the memory available to the application.

Let’s be honest: there has been plenty of testimonies from academics that the original name entailed inappropriate behavior ranging from bad jokes to harassment. I hope this renaming will contribute to reduce – at least a bit – the leaky pipeline in this area of CS.

Once you have a joke that works, you can reuse it in every applicable context. Requiring us to come up with a new joke may require significant additional development and testing time.

So… is this comment an old, proven joke, or a new joke that you’re testing? :-)

My point is that Rust project isn’t falling into “terminal bureaucratic decay” because this is how the project has always worked. This is an adjustment to an organizational model that has already succeeded in bringing us the Rust we have today. If you think there ever was some BDFL who is definitely responsible for Rust’s success, you are wrong.

The point is that almost no meaningful decisions come down to “two people disagree”. If two people feel strongly about disagreeing, the question probably merits an RFC.

Ah, OK. Sorry, I misunderstood.

Languages also won’t prevent bad designs, bad performance, hard, unreasonably complicated builds and deployments, bugs (security-related or other kinds), and so on.

No, languages exist exactly to do these things. I’m excluding the extreme case of someone stubbornly writing intentionally terrible code to prove the point. When developers write code with best intentions, the language matters, and it does help or hinder them.

No, they don’t.

• Bad designs are a factor of developer experience
• Performance is a factor of algorithms and implementations
• Complicated builds are based on design, build tools, libraries, frameworks, also see Bazel, etc.
• Deployments pretty much the same thing. I’d agree with builds and deployments language can have a huge influence, which is why containers are often used as a workaround. If we look at C code there is a huge range starting from super simple, single binary to absolutely horrible. So that’s why I don’t think it’s defined through the language.
• Bugs are to a large degree ones that can be made in every language. There’s so many bugs that have been done in C, Java, Python, Perl, PHP, Go and Rust. From bad error handling, over SQL injection, library misuse, etc. Sure, if your implementation has memory safety it is it’s own story, but it’s certainly not the only and not the only security critical bug.

We have type systems, so that a “bad programmer” calling a wrong function will get a compilation error before the software is released, instead of shipping buggy code and end users getting random “undefined is not a function”.

Yes. Yet there were C and C++ and people still came up with Perl, Ruby, PHP which all don’t have memory safety issues.

You can have standard libraries that provide robust fast containers, good implementations of basic algorithms, so that you don’t poorly reinvent your own

You can also have different implementations, replacements for standard libraries, other algorithms, because it’s not tied to the language.

Consider how GTA was terribly slow loading for years because of a footgun in a bad standard library combined with a crappy DIYed JSON parser.

This underlines my point though. Despite the language that is usually called fast it’s slow. Despite the language it was made fast. So it was not the language defining the software, but these factors.

It’s much harder to write bad Rust code than to write bad C or bad JS or bash. Good languages make “bad programmers” write better code.

While I agree with that sentiment, I’d be curious about any studies on that. Way back when I was at university I dug through many studies on such topics. From whether object oriented programming has measurable benefits, to typing, over development methodologies, and so on. In reality they all seem to have a lot less (that is no statistically significant) difference, from bugs to development speed over so many other factors. They always end up boiling down to developer experience and confidence. Unless there were biased authors.

I think a great example is PHP. I think a lot of people here will have seen terrible PHP code, and it’s a language I like to hate as well. It’s incredibly easy to write absolutely horrible code in it. Yet the web would be empty without. And even new projects are started successfully. I can’t think of anything good about it really, and I try to stay away from it as much as I can, yet even after decades of better alternatives new projects are frequently and successfully started based on it. And there’s some software in PHP that a lot of people here would recommend and often write articles about here. Nextcloud for example.

[Sorry, this is a longer response, because I don’t want to be misunderstood here]

That’s an abstract/theoretical example though. In reality I will gladly use nginx, OpenSSH, etc. over what exists in Rust, but not because of the language choice, which is the whole point I am trying to make. At the same time I wouldn’t trust other software written in C.

Let me ask you a question. Would you rather build your company on a real life kernel connected to the internet written in C or in Rust in the here and now?

I am maybe a weird one out, but I usually take a look over the code and project that I am using. There is situations where C code is simply more trustworthy. Often in “new” languages you end up with authors basing on stuff that is new themselves, so you can end up being the guinea pig. There’s also a couple of signs that are usually good for a project, not because you need them on your own, but because they are a good factor for maturity. One of them is portability. Another is not just throwing a docker container on you, because the build is to complex otherwise.

And of course these things change. Might very well be that in future I’ll use a Rust implementation of something like OpenSSH (in the sense that OpenSSH isn’t just an implementation of the protocol). But right now in the real world I don’t intend to. I’d be way too worried about non-memory safety bugs.

But let’s go a bit more abstract than that. Let’s talk an abstract service and let us only focus on how it is built and not what it actually does. If I got to choose between an exposed service under your premises in memory-safe node.js/JavaScript or in non-memorysafe kcgi/C and my concern is being hacked I can see myself going for the latter.

In your example, sure I’d go by Rust. But the thing here is that it’s because of missing context.

But it isn’t language dependent. For example for non-language factors I am pretty certain that there is more PHP and more node.js code out there with SQL injection bugs than probably in Python and Ruby. Does that mean I should choose the latter if I am interacting with databases? I’d also assume that in the real world on average node.js applications are more susceptible to DOS-attacks (the non distributed version) than for example PHP, simply because of how they are typically deployed/run. That also doesn’t have much to do with the language.

I am focusing on the title of the article here. “Software is not defined by the language it’s written in” I really don’t think languages are the thing that defines software. I’ve seen surprisingly good, solid Perl code and I’ve seen horrible Java, Python and Rust code. The reason for that was never the language. Other examples I can think of is when Tor was still in C (and they switch to Rust for good reasons, pretty successfully), and there are similar project in Java and Python for example. But I wouldn’t use them, because while they are written in a memory safe language I’d trust Tor more.

I think the usual reason why a project is started in a certain language is this. A developer has a number of values, usually also found in the project. In the time when the project is started people with these language gravitate towards a language or a set of them. So when you look at a project and the chosen language you will usually see a time capsule of how languages were viewed during that time. But these views change. A project is started in C for other reason than 10, 20, 30 years ago. The same is true for Python, Go, and even Rust has seen that shift already. While the “more secure than C/C++, yet more performant” is a constant theme, things like web assembly, adoption by projects, even changes in the language are a factor that made people use or not use Rust for new projects (anymore).

Sorry for a late reply.

It is definitely a problem. It makes it hard for two organizations to create shared streams. This comes up e.g. when an organization with Zulip for internal communications wants to contract another company for e.g. software development and wants them to integrate into their communications. The contractor needs accounts at the client’s company. Moreover, if multiple clients do this, the people working at the contracted company now have multiple scattered accounts at clients’ instances.

Creating stream shared and replicated across the relevant instances would be way easier, probably more secure and definitely more scalable than adding wayf to relevant SSOs. The development effort that would have to go into making the web client connect to multiple instances would probably be also rather high and it would not be possible to perform it incrementally. Unlike shared streams that might have some features disabled (e.g. custom emojis) until a way forward is found for them.

But I am not well versed in the Zulip internals, so take this with a couple grains of sand.

EDIT: I figure you might be thinking of e.g. open source projects each using their own Zulip. That sucks and it would be nice to have a SSO service for all of them. Or even have them somehow bound together in some hypothetical multi-server client. I would love that as well, but I am worried that it just wouldn’t scale (performance-wise) without some serious though about the overall architecture. Unless you are thinking about the Pidgin-style multi-client approach solely at the client level.

It took me awhile, but the source of my claim is from VSCodium itself, and this blog post:

https://www.roboleary.net/tools/2022/04/20/vscode-telemetry.html

https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetry

Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.

Also, in 2021, they apparently tried to deprecate the old setting and introduce a new one:

https://news.ycombinator.com/item?id=28812486

https://imgur.com/a/nxvH8cW

So basically it seems like it was the old trick of resetting the setting on updates, which was again very common in the Winamp, Flash, and JVM days – dark patterns.

However it looks like some people from within the VSCode team pushed back on this.

Having worked in big tech, this is very believable – there are definitely a lot of well intentioned people there, but they are fighting the forces of product management …

I skimmed the blog post and it seems ridiculously complicated, when it just doesn’t have to be.

So I guess I would say it’s POSSIBLE that they actually do respect the setting in ALL cases, but I personally doubt it.

I mean it wouldn’t even be a dealbreaker for me if I got a fast and friendly markdown editing experience! But it was very laggy (with VSCodium on Ubuntu.)

At the risk of belaboring the point, it’s a dark pattern.

This was all extremely common in the Winamp, Flash, and JVM days.

The thing that’s sad is that EVERYTHING is dark patterns now, so this isn’t recognized as one. People will actually point to the page and think Microsoft is being helpful. They probably don’t even know what the term “dark pattern” means.

If it were not a dark pattern, then the page would be one sentence, telling you where the checkbox is.

That is an … interesting … design choice.

How would you do this differently? The same is true about any system with plugins, including, eg, Emacs and Vim: nothing prevents a plug-in from calling home, except for the goodwill of the author.