bakul

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.

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.

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

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.

> just terminating a goroutine isn't safe with respect to I/O and defer chains.

Agreed. The idea is to panic() if a goroutine has to be forcibly terminated due to GC, instead of a slow leak. Requires more thought though.

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.

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.

Proof is in the pudding etc.! I'm certainly curious how well your design & implementation will turn out. Good luck with your project!!

> 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 :-)

Thanks; just the kind of response I was hoping for! Is the problem an inability to express real world design constraints in a high level HDL?

Have you looked at/used Bluespec SystemVerilog? If so, any comments based on your experience?

https://github.com/B-Lang-org/bsc

You may still have N crossings: user process -> uK -> fileserver -> uK [-> generic Disk driver -> uK] -> specific device driver -> ... and concurrently some thread/process scheduling has to happen as there may be many such things in flight at the same time.

All this has been thought about for decades. I encourage you read KeyKOS related papers on Norm Hardy's site (link in my earlier response). seL4 is of course a very good uK but it still have not taken over the world (its niche is probably high security environments).

Microkernels + userspace drivers end up with too many context switches. This has been the main issue with microkernels. Then you add performance sensitive services in the "microkernel" and it stops being micro! Note that KeyKOS has a microkernel arch. but they called it "nanokernel" to distinguish from all the other fat "microkernels". They even prototyped a Unix service called "KeyNIX". See http://cap-lore.com/CapTheory/upenn/NanoKernel/NanoKernel.ht...

Plan9 in fact uses file descriptors all over the place, including accessing synthetic or real filesystems (which are really namespaces). In fact the only "globals" are the #<dev> devices.

IMHO you're better off starting with plan9 concepts + pure capabilities (KeyKOS as opposed to Capsicum). It would not enough to have a clean architecture unless a) it matches or improves upon performance and b) there is a way to run existing Unix software via some adapter layer or library or monitor.

I suspect if you try to "reform" unix, there will be a lot of recidivism :-)

Plan9 gets a lot of this right.

The author should flesh out why "Unix is bad".

The "Monte-Carlo tree search" space is usually far too large for this to work well!

It is true that initially you may not know where the bug is but you have to collect more evidence if possible, see if you can always cause the bug to manifest itself by some tests, explore it further, the goal being to form a hypothesis as to what the cause may be. Then you test the hypothesis, and if the test fails then you form another hypothesis. If the test succeeds, you refine the hypothesis until you find what is going wrong.

Such hypotheses are not formed randomly. You learn more about what may be the problem by varying external conditions or reading the code or single stepping or setting breakpoints and examining program state, by adding printfs etc. You can also use any help the compiler gives you, or use techniques like binary search through commits to narrow down the amount of code you have to explore. The goal is to form a mental model of the program fragment around where the code might be so that you can reason about how things are going wrong.

Another thing to note is you make the smallest possible change to test a hypothesis, at least if the bug is timing or a concurrency related. Some changes may change timing sufficiently that the bug hides. If the symptom disappears, it doesn't mean you solved the problem -- you must understand why and understand if the symptom disappeared or the bug get fixed. In one case as I fixed secondary bugs, the system stayed up longer and longer. But these are like accessories to the real murderer. You have to stay on the trail until you nail the real killer!

Another way of looking at this: a crime has been committed and since you don't know who the culprit is or where you may find evidence, you disturb the crime scene as little as possible, and restore things in case you have to move something.

But this is not usually what happens. People change things around without clear thinking -- change some code just because they don't like it or they think it can be improved or simplified -- and the symptom disappears and they declare success. Or they form a hypothesis, assume it is right and proceed to make the "fix" and if that doesn't work, they make another similar leap of logic. Or they fix a secondary issue, not the root cause so that the same bug will manifest again in a different place.

Do SE classes teach debugging skills? I hope they do. So many times I have seen people try random things rather than follow a systematic approach.

iAi

More Mungers, fewer punters?

This is as meaningless a question as “if you could only eat one thing what would it be?”. You may have a favorite food but you need a balanced diet!

If new people are properly (but gently) mentored, they are more likely to do things the “right way” that’ll reduce maintainers’ work from any future contributions from them.

I haven’t visited your website but just the title makes me think of IBM Lotus iNotes groupware (or whatever it was called) that had many integrated apps such as calendar, email, schedule, to do list manager, notebook, some sort of forms manager for filling expense reports and such, etc etc and was an absolutely nightmare to use. IIRC it had a web based interface as well as a stand-alone program. It was so bad I have blocked out all memory of using it!

Invariably all in one products fall behind as new capabilities are needed as the user base grows and their needs evolve. Integrating new functions gets harder and harder. What I’d like to see is a graphical version of the Unix philosophy of making it easier to connect together programs, each of which handles one kind of thing, with a “shell” around them. May be come up with a richer, self describing data structure to interconnect these apps.

Why not simply use mmap judiciously in a program managed shared memory ring buffer? Then you can copy at roughly memory speed.

My mom used to make a variety of achār (athāṇuṁ in Gujarati). Sour, sweet ones (made with unripe mangoes and they both had mustard & red pepper in oil), Chhundo (shredded unripe mangoes in sugar syrup & red pepper). These would be stored in white & light orange ceramic pots. But I don’t recall them lasting years and years! Lime as well as green pepper pickles were more seasonal. Also whole not quite ripe black peppers on their stem. The green pepper ones would get less hot over time but some could still be tongue burning hot.

People who want to make their own pickles should first try readymade ones as they can be a bit of an acquired taste. You can get many kinds in most Indian stores (usually a at least a whole shelfful if not a whole aisle). Patak’s used to be the main one many years ago but now there are many more brands. My favorite is Patak’s brinjal (eggplant) pickle. You can even use some pickles as a sandwich spread! Or on crackers or lightly sautéed chapati or masala puri etc as a quick snack.

Perhaps you can just use https://github.com/aclindsa/ofxgo - it seems to be a pretty good Go package (just eyeballing it, haven't use it).

Very good! Thanks!

Looks good! Paisa Vasool! Especially as it is free :-)

You don’t have to, of course, but do you plan to open source it? That way others can contribute to it too.

How tightly is it bound to ledger? How hard would it be to adapt it to other plaintext accounting programs like beancount?

I’ve used LT since 2006. I like its interface which presents a lot of information on one page instead of lots of white space. And I like its features, groups, discussions etc. Though my use has dropped off now.

Some C programs, not all. For example Andy Sloane’s donut.c. Granted, it is beautifully obfuscated but still, it uses just standard C features.

https://www.a1k0n.net/2006/09/15/obfuscated-c-donut.html