Yes, once it was technically possible. I think interesting idea is from a Human Factors perspective. I contend from human factors perspective using 24ish hours is good technical limit. Most humans operate on a 24 hour cycle so keeping devices on that cycle has a certain simplicity. It is easy to communicate and shares a historic limit with its mechanical ancestors.
This could also help in keeping the battery size in check. The engineering of all aspects should be balanced.
Did anybody mention plan9? At any rate it is not a microkernel. There is at least one effort implementing v6 unix in rust. That would probably meet your minimum requirements!
Note that "mudras" have significant meanings in Hinduism, Jainism & Buddhism. Mudras used in Indian dances convey feelings or elements of story etc. Also used in yoga. And mudras are not just hand gestures but also facial expressions, eye movements and so on.
Though there does not seem to be any connection of mudras with European paintings. There were cultural links between India and the Greco-Roman world in 2nd-1st century BCE around the time of Indo-Greek kingdom (northwest of the current India) but seems unlikely that would have such an influence centuries later.
Diclofenac has been banned in India for veterinary use since 2006. Another NSAID that is not deadly to vultures is recommended for such use. Not sure why Guardian ran this story now as this is old news. The real crisis with plunging vulture population goes far beyond Zoroastrian burial rites. See https://en.wikipedia.org/wiki/Indian_vulture_crisis
That Wikipedia article is what made made curious, as it says "drugs like diclofenac..." From that small bit, it seems like the many NSAID's given to humans such as ibuprofen or asprin could be issues. Even diclofenac seems to have some human use.
I suspect stronger drugs such as codeine etc are used for palliative care of humans in their last stages. Not sure of their effect on vultures. Parsi numbers have never been high and gradually decreasing (now about 70,000 in India), also they mainly live in relatively few places, most in Mumbai and nearby. The vulture population dropped from 40 million to a few hundred so the primary cause must be from their non-human diet.
Low fertility rates (like in most well to do communities), interfaith marriages (if you marry a non-parsi and your kids are not considered parsi), aging population, migration out of India.
If Go allowed something like "handle = go foo()", goroutine could be automatically terminated when handle goes out of scope or becomes dead and is garbage collected. You can also use handle to cancel a goroutine etc.
Go designers specifically avoided this model (of having a goroutine "id") for reasons I don't remember any more (may be to avoid making them heavier weight?) but this would be one way to stop leaky goroutines.
It's because just terminating a goroutine isn't safe with respect to I/O and defer chains.
I think Go has the internal plumbing to theoretically support this, though it might require inserting checks more often. Another way would be to make contexts first-class and automatically insert context checks even when not done (e.g. selects). And also all I/O has to be cancellable.
I suspect Go's designers prefers the current way in which cancellation is explicit.
Let me try to explain. The current way (which must continue working the same way even if the language is changed) does not allow you to distinguish a goroutine that should terminate but hasn't due to some bug versus a goroutine that can legitimately run for a long time. Making the goroutine "id" explicit can allow you distinguish the two cases. Store the id in some global or long lived variable or array if you want the goroutine to run for a long time. Otherwise carefully control the scope of such an id so that the runtime has a chance to catch the first case. That is my initial thinking but it would need to be fleshed out more. For instance, there should be a way to test that goroutine has terminated. Currently you do this explicitly by passing a channel and waiting for a message.
The convention of passing ctx does almost the same thing though. Make a new context.WitCancel and pass it to the goroutine.
It just requires programmer cooperation, but as long as you pass ctx all through the stack down and handle err on the way back, it is not often you deal with it explicitly.
It does, but feels extremely bolted on(because it was). To do properly , near every single function and method has to take a context, which gets repetitive. Then every single thing in the call stack needs to actually check for cancellation.
It feels like something similar should be baked in, and inherited from its parent by default(but overrideable). And a cancel would cancel the callstack. Would be nice to make this cleaner in go 2, I think.
If you actually code in go there, they expect you to handle it yourself though by not orphaning goroutines. Err groups or similar will take care of this. Basically it's people writing bad code because they can. There's already options to handle it available.
One can think of s-expr parentheses as structural formatting commands - sort of like markdown. Then you can render an s-expr in a different way so long as the structure is maintained. For example choosing diff background color at each level or for different types of s-expr.
I think it is more correct to say that religion has been used as an easy excuse and a way to bind closer the group causing violence and to dehumanize the victim group.
> The current filesystem semantics are terrible for databases
There was at least one Unix startup (IIRC it was Tolerant Systems) in mid 80s that applied transactional semantics to filesystem operations. I did some contract work for them and found the performance was absolutely abysmal and the system had some deadlocks. Now may be their implementation was not great but I suspect the converse is also true: database semantics are terrible for filesystems :-)
There was at least one database from the mid 80s with abysmal performance and deadlocks too. But plenty of modern databases are fast and correct. The fact this one startup 40 years ago didn’t solve the problem doesn’t say a lot about whether I’ll be able to. Honestly the fact there are some dead bodies on the mountain makes it more fun to give it a go and see how I do.
To be frank, judging by the code I’ve seen over the years, most engineers don’t have a lot of experience or skill at making software run fast.
reply