Do you have a union in your business?
If not, why not? If yes, what is the experience like?
896 karma · joined July 12, 2016
You could either schlep the hard disk or try to carry 20 - 30 floppies around
With a high chance of at least some of them bring bad
I was trying to explain how my 12 years old self saw that code
And I had no other resource to turn to at the time
You don't need it global
Seed it once per thread from /dev/random and you are done
It also has a lot of eyes on it and was reviewed by people whose job is to spot these sort of issues
Sounds like the other size of timing leaks that cryptographers are so worried about
All you need is to e loitering nearby, connect and drop the data then move
But phyaical tracking is very much a threat
But remember that we rely on the lambda scheduler to run it
That does boy have perfect accuracy, so that helps too
Finally, you aren't publishing every 5 minutes, you execute it once a minute, and have 25% chance to publish, so it's going to be mixed
Note stenography will not actually help if your data is searched for.
Obscurity isn't a protection method
The idea is that you can't tell how many encrypted items you have in the output without the secret key
This will not hide that the data is encrypted, sure, but will allow you to reveal the innocent pieces only if required
Given a two years gap, you should invest the time and effort in learning whatever it is the market is seeing demand in.
Consider the employer's perspective. Given two equivalent candidates, where one of them know Spring, but the other needs a month or so to learn it. They'll go with the one that already knows that.
That attitude of I can learn on the job is likely hurting your prospects.
The CV in the website is also really bare bones. Basically, nothing relevant there. The old one appears to at least show the employment history.
The website link from GitHub is erroring. The website you linked looks bad, Geocities bad.
The GitHub profile itself is really bare bones. The first non-forked repository I saw was literally hello world (hidden by many layers).
Don't assign small number of tokens, but a much larger one
If you have a million tokens, there is no need to re-shard, and you can re assign tokens to different nodes as your cluster grows
Consider that you just spend a few millions on training a model on copyrighted data. Release it would reveal that, problem.
I _guess_ you can try doing training in the public, like Seti @ Home or something like that, which distributes the risk? But no idea if this is even possible in this context.
This way, you avoid extra allocation, copying, etc.
Assume 512 sectors ( I know those are rare ), but I don't think that there is any guarantees that 4KB page would be:
* Written atomically * Written in a particular order
Pretty much all storage libraries written in the past couple of decades are using single writer. Note that single writer doesn't mean single transaction. Merging transactions is easy and highly profitable, after all.
For fun, there is no guarantee in terms of writing a page in what order it is written. SQLite documents that they assume (but cannot verify) that _sector_ writes are linear, but not atomic. https://www.sqlite.org/atomiccommit.html
> If a power failure occurs in the middle of a sector write it might be that part of the sector was modified and another part was left unchanged. The key assumption by SQLite is that if any part of the sector gets changed, then either the first or the last bytes will be changed. So the hardware will never start writing a sector in the middle and work towards the ends. We do not know if this assumption is always true but it seems reasonable.
You are talking several levels higher than that, at the page level (composed of multiple sectors).
Assume that they reside in _different_ physical locations, and are written at different times. That's fun.
If Goldman is the one handling the lending, it is also the one sending you to collections.
The PR damage to Apple's brand can be significant
For example, if you hired someone in Israel, you are mandated to pay taxes, contribute to pension plan, etc. There are labor laws details that you need to know how to work through, etc.
As a fine example, let's say that you have hired someone in Israel and they worked for you for 5 years. You covered payment and told them that they'll cover local taxes, etc.
You now want to fire them.
The following sequence of events happen:
* They sue for wrongful termination (there is a particular process to follow) * They sue for missing pension contributions (the law says that if you didn't contribute to the pension, you are both civilly and criminally liable). And it can be that you are found to be effectively the "pension fund". * They sue for severance pay, which is calculated as 1 month of salary X years worked.
That can be a huge surprise for you.
That is leaving aside things like what happens around work accidents. Did you carry local insurance for that? Or are you on the hook for millions because of that?
Those are all things that can be solved, but they are a major headache.
GPL on server side software doesn't really matter, that is why the AGPL exists
Think an index, reading different files, etc.
Then the latency dominates
A truckload of TB disks will give you awesome bandwidth by driving it around to the destination.
The latency of a particular call, however, wouldn't make it usable.
Memory is hierarchical, but any latency beyond NVMe is non factor for treating remote data as memory
If you are using mmap, that will express itself as a segmentation fault, which you really don't want.
You _need_ to allocate the file ahead of time, so you can properly behave there.
There are many cases, and ingest is one of them, where no being durable is fine. If you can either:
* Repeat the whole process on failure (which is assumed to be rare) * Recover from the failure without data corruption (distinct from data loss, mind)
In those cases, being 10x faster is very compelling.
Note that this is about ingest for bulk loads, while online transactions not being durable is a really bad idea.
For bulk load ingest, you can usually retry the whole operation. Not so for transactions.
https://ravendb.net/articles/re-are-you-sure-you-want-to-use...
Agree on CMU being a great resource.
``` { false, false, false, false, true, false, false, true } ```
It will give an int with the bits: `0b0000_1001`
You can then do `@clz` to get the index of the first set bit.
That would save you the `@reduce` and `@splat`. I don't see how to access move mask from Zig, however.
Note that the standard library has `std.zig.firstIndexOfValue`, which does what you have in the post, basically. And there is `std.zig.firstTrue`, which does the the same thing as `@clz` in this case, but I don't know what kind of assembly it will generate.