I don't think you can change user behavior like this.
You can give them a "venting sink" though. Instead of having a downvote button that just downvotes, have it pop up a little menu asking for a downvote reason, with "spam" and "disagree" as options. You could then weigh downvotes by which option was selected, along with an algorithm to discover "user honesty" based on whether their downvotes correlate with others or just with the people on their end of the political spectrum, a la Birdwatch.
A majority don't seem to be predictions about the future, and it seems to mostly like comments that give extended air to what was then and now the consensus viewpoint, e.g. the top comment from pcwalton the highest scored user: https://news.ycombinator.com/item?id=10657401
> (Copying my comment here from Reddit /r/rust:)
Just to repeat, because this was somewhat buried in the article: Servo is now a multiprocess browser, using the gaol crate for sandboxing. This adds (a) an extra layer of defense against remote code execution vulnerabilities beyond that which the Rust safety features provide; (b) a safety net in case Servo code is tricked into performing insecure actions.
There are still plenty of bugs to shake out, but this is a major milestone in the project.
Keyboards are higher bandwidth man-machine interfaces than mouse + GUI unless what you're exchanging is spatial information, which is typically not the case for writing software.
There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.
I use IDEA for most things and barely touch the mouse. It has its problems (like terrible performance), but it's a good example of a GUI done right.
Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).
Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.
This 100%. For me, the philosophy is not so much a terminal-centric design but a keyboard-centric design. Sure, this could be done in a GUI, but even GUIs with a keyboard-centric design are not as fluid as a TUI.
I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.
I didn't understand much of you said but it sounded mathy so I'm going to reply with a counterexample,
just look up on youtube Russ Cox solving AoC with Acme and tell me that's not impressive!
By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.
shorter traces than soldered DIMM allow higher MT/s, this is fixed by CUDIMM/CAMM2, the other part of this is # of memory channels on the board, not sure why, but most consumer DDR5 boards have been 2 memory channels, you need to go to threadripper to get 4 or 8, It's unclear to me if this will still be an issue with future platforms.
You're not paying enough attention to the performance and cost impact of connectors and sockets. CAMM2/LPCAMM and CUDIMM have yet to be demonstrated operating at speeds that speeds that match the fastest soldered LPDDR, let alone GDDR; there's still a clear advantage for soldering memory.
CPU sockets with more than two memory channels are also far more expensive; the higher pin count usually increases the number of layers the motherboard needs, and the larger size of the socket requires more metal for stiffening (and EPYC CPUs still have issues with imperfect mounting leading to some IO lanes not working).
Using BGA soldering for both the processor and the memory sidesteps a bunch of engineering challenges.
> Using BGA soldering for both the processor and the memory sidesteps a bunch of engineering challenges.
by trading them with longevity challenges.
Even though 2 decades have past after the "usual suspect" lead-free solder, gpu or vram chips needing a reball is still a common occurrence from a cursory look at YouTube channels of professional electronics repairmen.
reply