In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
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.
> Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG?
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).
Not for security but to make sure you don't accidentally reuse the same seed. I've done that before when the PRNG seed was the time the application started and it turns out you can run multiple instances at the same time.
> Does that mean that the admin will have to manage dob of every student when creating accounts ?
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
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
I'm not surprised; you need a lot more servers and even so, there are a lot of places where something low ping times is difficult. While there is a lot of room for latency to go down, 1 lightmillisecond is ~300 km (~186 mi). This means that if a computer is 150 km away, 1 ms is the minimum ping allowed by physics, if I am talking directly to it.
By that yardstick, we've actually done very well in a lot of cases. :)
Others in this subthread discussed the comparison of the complexity of different ways of achieving flight itself, but I think there is an interesting discussion in that... well... we do add senses we don't technically need to achieve stable flight (but are very useful for safe flight and have reduced the incidence of aviation incidents and accidents dramatically).
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.
> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
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
reply