This sort of bot punishes users for making even valid reports that aren't fixed immediately or missed by the maintainers for whatever reason including transitory ones, etc.

Constantly bumping threads/issues/whatever is generally considered rude, so this is why issue reporters generally don't do it, plus generally the reporter isn't solely focused on that particular issue

As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"

[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.

There's nothing about UUIDs that need to make them cryptographically secure. Many programming language libraries don't (and some explicitly recommend against using them if you need cryptographically strong randomness).

That already happens to some extent although the mechanism by which this happens might depend on the school district, etc. The `dateOfBirth` LDAP attribute is probably the most obvious method (which admittedly should probably not be used due to the ease in accessing this info in the default configuration) but there are others.

In secondary school when my account was set up we were told that our initial password (that we had to change on first logon) was our DOB

Relevant article from The Old New Thing: https://devblogs.microsoft.com/oldnewthing/20060509-30/?p=31...

Programs (this is true for most mainstream operating systems) can become network facing without realizing it. I've sometimes found a bunch of Windows programs sometimes tends to assume that I/O completes "instantly" (even if async I/O has been common on Windows for a very long time) and don't have a good UX for cancelling long running I/O operations

By that yardstick, we've actually done very well in a lot of cases. :)

Whether it be altimeters based on radio[1] or air pressure[2], avoidance and surveillance systems that use radio waves to avoid collisions with other aircraft[3][4], airborne weather radars[5], sensors that measure angle of attack (AoA), GNSS location, attitude, etc, many aircraft (even unpowered gliders!) have some combination of special sensing systems that aren't strictly necessary to take off, fly to a destination, and land, even if some are required for what many would consider safe flight in some scenarios.

Many of these systems have redundancies built in in some form or another and many of these systems are even built into unmanned aerial systems (UASes) big and small.

[1]: https://en.wikipedia.org/wiki/Radar_altimeter

[2]: https://en.wikipedia.org/wiki/Pressure_altimeter

[3]: https://en.wikipedia.org/wiki/Traffic_collision_avoidance_sy...

[4]: https://en.wikipedia.org/wiki/Automatic_Dependent_Surveillan...

[5]: https://skybrary.aero/articles/weather-radar

1. /sbin/init

2. /etc/init

3. /bin/init

4. /bin/sh

It dropping you into a shell is a pretty neat little way to allow recovery if you somehow really borked your init

Python doesn't use semver and never claimed to do so, but it's probably worth treating "x.y" releases as major versions in their own right (so like 2.7 -> 3.0 is a major version and so 3.10 -> 3.11). If you do that, the versioning makes a bit more sense

This is a lot of times what I see the "don't build for huge scale" to be. It's not necessarily "be proud of O(n^2) algorithms". Rather it's more "use Postgres instead of some hyperscale sharded database when you only have 10 million users" because the alternative tends to miss the forest (and oftentimes the scale, ironically) for the trees

It depends on what is considered memory safety here (especially when some of them are arguably unforced errors in the standards), but many implementations do in fact have options for this ("no delete null pointer checks" for example is an example of one such option, for example, which is used extensively by the Linux kernel for example).

The performance impact tends to be much more negligible outside of, sometimes contrived, benchmarks, especially when compared to algorithmic efficiencies or the like.

This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1].

Conforming programs do not have this requirement and basically any non-trivial C and C++ programs are written to this rather than the notion of "strictly conforming".

Most non-trivial programs are not strictly conforming (including some C compilers themselves), generally because restricting the set of targets to something smaller than "any possible C implementation" is useful.

It is perfectly legal (and very desirable in cases where the standards fall short of usefulness) for a C compiler to define undefined behavior. What you compiled is still a C program, just one that isn't portable across the entire potential set of implementations.

[1]: Or unspecified or implementation-defined, for that matter, but this part tends to get left out of discussions.

It is generally faster to communicate orally and process communication aurally than by text message when the message is short enough and requires immediate attention. This is also why urgent alarms (such as those provided by the Gound Proximity Warning System (GPWS) or Traffic Collision Avoidance System[1] (TCAS) have such a component). Some stall prevention systems are even partially tactile based (making a pretty unmistakable shaking feeling (it is loud as well)).

It is incredibly slow to type and then process that visual information. In addition, it's also just much more reliable.

For time critical situations, it's not a viable option.

[1]: Yes, TCAS has a visual component and many alarms do too, but the RAs are auditory and give specific, to the point, instructions on what to do ("climb", "descend").

On Linux you have some combination of Landlock, AppArmor, SELinux, calling prctl(PR_SET_NO_NEW_PRIVS), and the kitchen sink. On FreeBSD you have capsicum. Windows has integrity labeling + a bunch of stuff related to Job objects + a few things to disable win32k.sys calls.

But these are helpful and shouldn't be considered a panacea. The expectation is that you're delegating authority to a computer program to perform a certain task. Do computer programs abuse that authority sometimes? Absolutely. But nonetheless that's the fundamental model of most computer security, thanks in part to its usefulness.

And in the case of allowing setuid and filesystem views, the issue here becomes that an unprivileged user could create a view of the filesystem that has an /etc/passwd and /etc/shadow file that the attacker knows in their home directory. Run some setuid program (like su or sudo) with this view and we've successfully became root, breaking out of the sandbox.

And you can't whitelist /etc/passwd or whatever either. This is why allowing anyone to play with mount points is fraught with danger.

Now is suid/sgid a fundamental part of a Unix-like system? No, but setuid was created in the world that was and even though these are arguably bugs, releasing a Linux kernel that creates a bunch of security holes in userspace is a very very bad breakage of userspace.

---

No New Privileges does make this a bit better (as you can never gain more privileges than you already have, and this is a one-way door) and the kernel docs even say that eventually unshare or chroot may be allowed when operating under no new privileges

But this is currently why you can't chroot as an unprivileged user as you can trivially blow through the security domain on most Linux distributions

There is probably a wide breadth of software that is actively not using that glibc version.

But yeah, agreed that trying to do localization with the builtin functions are fraught with traps and pitfalls. Part of the problem though is less about localization and more due to the fact that you can have bugs inflicted on you if you're not careful to just overwrite the locale with the C locale (and make sure to do this everywhere you can)

[1]: https://sourceware.org/bugzilla/show_activity.cgi?id=1890 (see specifically the target milestone, the 2023 date seems to be overly pessimistic)