That is incredibly stupid. A documentation system designed by someone who doesn't understand how people use documentation.
If man was designed by someone with any taste at all it would at least give you a menu to select (1) crontab command, (5) crontab file format. Maybe we need a rewrite in Rust to fix that.
Programs these old are controlled by people who are very strongly opposed to change, even if it improves things. They like living in the 80s.
I absolutely guarantee if you propose this change the the GNU neckbeards who control man they will come up with some bullshit technical reason why it can't be done.
And since man pages could take minutes to print out, if you needed one you'd tear that section of paper off and keep it in a binder for future (and faster) reference.
No, equal. If the profit gained from buying/selling gold in New York and doing the opposite in London is not equal to the cost of physically transporting the gold across the Atlantic then there is and arbitrage opportunity and in a perfect market it would be eliminated until those costs are exactly equal.
In reality markets aren't perfect, and also you'd have to take into account the benefit that doing things digitally is much faster, so it won't actually be equal. But in the magic world that economists live in it should be.
A keyword seems nicer to me. I think the only reason to use attributes is to avoid the work of adding actual new syntax, but seeing as they've already done that...
Ugh that brings back bad memories. I remember it was supposed to be the answer to MFC. I did an internship where my boss wanted me to use it. It was very painful because it had basically no documentation at all.
That's rose-tinted. I remember specifically switching to KDE because GTK apps of the day segfaulted all the time. Unfortunately KDE then screwed things up massively with Plasma (remember the universally loathed kidney bean?) and it's really only recovered recently.
And to say the desktop experience was more polished than what we have now is laughable. I remember that you couldn't have more than one application playing sound at the same time. At one point you had to manually configure Xfree86 to be aware that your mouse had a middle button. And good luck getting anything vaguely awkward like WiFi or suspend-to-ram working.
The Linux desktop is in a vastly better position now, even taking the Wayland mess into account.
OCaml has a lot of other cons though that Rust doesn't have. I would definitely pick Rust over OCaml even for projects that can tolerate a runtime with GC pauses. (And clearly most people agree.)
The ecosystem. The language is lovely, but dune/opam is not up to the standard of the Go or Rust build systems, and the set of useful libraries is somewhat skewed. Whenever I write a program in Caml, I gain an hour thanks to the nice language, and then lose two fighting with dune/opam.
There's also the support for concurrency and parallelism, which has started to improve recently, but is still years behind what is available in Go (but still better in my opinion than what is available in Rust).
For example, multicore OCaml is not free of race conditions.
The GC, while super efficient (pauses are in the milliseconds), is not suitable for hard realtime.
Still, where absolute max performance or realtime are not required, I'd choose OCaml as it is elegant & a pleasure to code in (personal opinion, ymmv).
Poor windows support, confusing and buggy tooling (yeah really), mediocre documentation, global type inference, weird obsession with linked lists leading to performance gotchas, difficult syntax (yeah really), small community.
I can expand on any of those if you disagree with them.
Well that seems like an unreasonable expectation no? Also isn't the point of spinlocks that they get released before the kernel does anything? Otherwise you could just use a futex... Which maybe you should do anyway...
The scheduling is based on how much the LWP made use of its previous time slices. A spinning program clearly is using every cycle it's given without yielding, and so you can clearly tell preemption should be minimized.
reply