HN user
-
The actual issue is that Windows and Linux don't properly use a ‘super’ key―while the ‘Win’ key is sitting there uselessly.
These keys are great to use on Mac
The use of the super key on Mac is horrible. It should sit there uselessly, until I tell it to do otherwise. On Mac, here are no safe hotkeys to bind anything to. On Linux, my WM configuration has a ton of actions bound to the super key, and I never have to worry that it will conflict with another application.
there is no sharing of objects across threads
You can message-pass a pointer if you are sure the referenced object won't be GCed.
You communicate via channels, like in Go. Objects passed through a channel are deep copied. To share an object, you can create an actor thread that owns it, or if you're sure the object won't be GCed (i.e. by exempting it with the `GC_ref` function), you can pass a pointer through the channel.
She literally addresses this in the video you linked: https://youtu.be/UGL_OL3OrCE?t=1757
They spent a lot of effort ensuring that their imaging methods were objective and free of human bias.
This was recently posted on HN. It actually got me thinking how I might write a service like OP's.
I wrote a story that became a legend. Then I discovered it wasn’t true: https://www.cjr.org/first_person/tinazzi-motorcycle-mont-bla...
They were composing their first Reddit post as they came through the birth canal.
Ok, I got it. They're exactly the same. Either way you'd need to do a second search, because you're trying to differentiate between 3 states: "probably a match", "empty", or "deleted". A much better way than stealing a bit from the hash prefix is using a special value that represents "empty or deleted", and that's exactly what SwissTable does: https://github.com/abseil/abseil-cpp/blob/256be563447a315f2a...
That's a great point. It's still a possible optimization with a compare-and-swap or if you can determine that you're in a single threaded context.
And so our "two loops" are usually just "do two simple SIMD operations". Not quite so offensive when you say it like that!
No, it's not quite so offensive, but this doesn't explain why it's the best option. Is there no equally-fast way to write the first-tombstone implementation with SIMD instructions? The answer seems to be in the sketch of the implementation, which I'm having trouble understanding.
EDIT: I'm watching the original SwissTable talk now... would it really have been worse to use 2 bits for empty/tombstone/full/sentinel, and 6 bits for hash prefix?
EDIT 2: More implementation info. Tombstones are actually rare, because if any element in your 16-wide chunk is empty, you don't have to create a tombstone. In the very best case (a perfectly distributed hash function), your hashmap has to be ~94% full before it's even possible to fail this. Because tombstones are so rare, it's better to save the single bit for extra confidence in the hash prefix.
So, here is my understanding of the implementation and its rationale:
* Every bucket in the backing array has a corresponding byte in a metadata array
* 1 bit of this byte stores whether the bucket is empty, the other 7 bits are for a hash prefix
* SIMD instructions search 16 bytes at a time, checking: this bucket is not empty, this bucket's key matches the first 7 bits of my key
* Since 16 buckets are checked for emptiness at the same time, you can avoid creating a tombstone for a bucket if any of the other 15 buckets are empty (just set it to empty, i.e. set the first bit to 0)
* This means that tombstones are very unlikely- you'll probably rehash before you get to the load factor where you start seeing tombstones
* Since tombstones are so unlikely, it's more valuable to add an extra bit to the hash prefix than it is to quickly find tombstones
My question remains: why can't the first search return the offset of the first empty bucket? In this loop, why is there not an else that saves the offset?: https://github.com/abseil/abseil-cpp/blob/256be563447a315f2a...
I would argue that "the table" is not mutated, only the internal state of its implementation. Every time you access any information, a cache at some layer below you is updated. Is that also gross?
I always assumed that the loud noise reduces sensitivity, tuning out some quiet signals like tinnitus. Same thing as not being able to hear well after a loud concert.
My argument was only that bringing the cost down would make it easier to build a more reliable P2P network. I doubt that reliability/cost are the main reasons P2P networks aren't more popular, rather that the average person doesn't really care or even know about their existence.
Such a compression algorithm could make it much cheaper for the community to volunteer capacity to the network (short-range relays? data storage nodes? crowdfunded cell towers?), which could make it much more feasible to build a reliable P2P network.
WINE + DXVK can pretty much run any modern game (with varying performance).
OK
The two could use mutual TLS with baked certs
In Seattle, most people I know choose Lyft for ethical reasons.
etcd, kubernetes, docker, rkt, grafana, cockroachdb, elastic beats
81 of the top 100 sites on the web use HTTPS by default
I find it disappointing that there are any sites that large that are using HTTP.
I assume there's a similar patch for the Mac client, but this offers no protection for users running the Windows client via WINE.
I don't see the point... QWERTY is great for touch screens, for the same reason it was great for typewriters: common letter combinations are spaced out. Typing with two thumbs on a small screen is comfortable due to greater space between keys and high rate of alternating hands.
It does matter, because your argument categorically does not apply. Brave is not involved with the distribution of content.
That's not what's happening, though. Brave is not running a streaming video service. They aren't hosting or distributing the content. There's nothing illegal about holding money and pledging to give it to someone if they ask for it (as long as you actually do).
When I clicked this article, I was expecting to see that someone had gotten Skyrim working with AAlib.
Are you worried about your chip and OS today?
Yes, Intel is still pulling these stunts and there are not many viable alternatives.
there's no evidence that DVORAK is better than QWERTY
Here's my go-to reference: http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts
Docker takes about 10m to build: https://jenkins.dockerproject.org/job/docker/job/docker.gith...
Kubernetes takes about 16m: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/...
Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable.
[0] https://nim-by-example.github.io
Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.
EVERY OTHER CONNECTOR has gone through improvements. new USB standards. new video. everything. why is this any different?
Physical improvements have been necessary for USB to increase bandwidth. 3.5mm is a connector for carrying two (sometimes 3) analog signals, and backwards-incompatible changes aren't necessary until we develop a third ear.