singron

This implementation uses unsafe. You can write a linked list in safe rust (e.g. using Rc), but it probably wouldn't resemble the one you write in C.

In practice, a little unsafe is usually fine. I only bring it up since the article is about translating to safe rust.

I usually reduce the width of my browser window, but reader mode is a great idea too. I like the minimal aesthetic, but text width is so important to readability that danluu really should add a max width.

What you describe is kind of like a theoretical heat exchanger that only averages temperature at a single point.

You can improve this by exchanging heat across a continuous length along opposing flows. Imagine two parallel pipes thermally bonded where fluids flow in opposite directions. Each point still averages the temperatures, but the average temperature varies across the length and approaches the interior temperature on the interior side and the exterior temperature on the exterior side.

Part time makes sense for a company if it's a specialized role that they can't saturate with 40 hours of work per week but still need on an ongoing basis. E.g.

* Remote hands for 10s of racks at a datacenter

* SOC2/auditing paperwork

* Customer service

* DBA

* Accounting, HR, and other backoffice

For most other roles (e.g. developing product software), the company would rather onboard the minimal number of people to finish quickly, so they will want full-time. It's pretty rare that a company needs part-time work for a fixed-length project, but it's sometimes useful if it's a small part of a larger project. E.g. a designer could be part time on a typical web-dev project once implementation starts.

A really good tester would be awesome to hire for 1 hour per day, but it seems like that part of the industry is unfortunately a race to the bottom, so it's probably hard for talented people to get paid what they are worth.

People complain about having to reinvent major discoveries in interviews, but in my experience this is very rare. The overwhelming majority of coding questions are more advanced versions of fizzbuzz, which merely require reapplication of common techniques. It is very frustrating as an interviewer if nobody can solve your questions, so the questions used will evolve to things that the typical competent applicant usually solves.

There is a retention policy, so the raw events aren't kept very long. The rollups probably compress really well in their time series database, which I'm guessing also has a retention policy.

If you have high cardinality metrics, it can still be really painful, although I think you will feel the pain initially and it won't take years. Usually these systems have a way to inspect what metrics or counters are using the most resources and then they can be reduced or purged from time to time.

Any IC that would be practical to DIY is available for <$1 and you could probably get something 1000x more powerful for nearly the same price. Making chips isn't the issue here.

The better version of this is sagas, which is a kind of a simplified distributed transaction. If you do this without actually using sagas, you can really mess this up.

E.g. you perform step 2, but fail to record it. When resuming from crash, you perform step 2 again. Now A has too much money in their account.

Maybe it it was assigned to a single organism, but it's probably a work for hire.

I think this article isn't considering wifi. Most early sites were pressured into using SSL because you could steal someone's session cookie on public wifi.

Without cryptography, all wifi is public, and in dense areas, you would be able to steal so many cookies without having to actually get suspiciously close to anything.

I'm guessing without crypto, we would only access financial systems using hard lines, and wifi wouldn't be nearly as popular. Mobile data probably wouldn't have taken off since it wouldn't have been useful for commerce.

Is 800 euros that bad? In the US, we were quoted $10k a few years back. Even if fiber is already at the road, $800 is probably a fair price just to trench the line from the road to your home and install an entry point. If they provide free installation, then they have to make up the cost by raising your rates.

Is the syllable still the Mark if you pronounce it with a soft G instead of a hard G?

Yeah this was weird. You usually expect this from a newspaper where the editor chooses an inaccurate headline, but this is iFixit? The actual text of the article points out that just about every McDonalds franchise will be unaffected and have equally broken ice cream machines, which is why it's so weird that they contradict that in the headline.

If the stock is liquid, then this makes sense. However, if it's not, then you might not want to hold that much stock (or especially options) in a single company. It's also common for the refresher grants to be much smaller, especially if you were an early employee.

This was really interesting. I don't love the fading out to solve the moire in the final solution. I wonder if some dithering would feel better and give the impression there are lines out there rather than a smooth gray surface? Or maybe some jitter to break up the pattern?

This isn't shown in the post, but sometimes the moire feels worse if you are walking around and the moire has a movement of its own (either flickering/shimmering or sweeping across in uv space), and it's probably a decent benefit to get rid of the moire even if it's imperfect.

We once accidentally made a change to a python project test suite that caused it to successfully run none of the tests. Then we broke some stuff but the tests kept "passing".

It's a little difficult to productionize an always_fail test since you do actually want the test suite to succeed. You could affirmatively test that you have non-zero passing tests, which is I think what we did. If you have an always_fail test, you could check that that's your only failure, but you have to be super careful that your test suite doesn't stop after a failure.

The build time is pretty significant actually. E.g. NixOS takes this to the extreme and always rebuilds packages if their dependencies change. It can take days to rebuild affected packages, and you typically can't easily update in the meantime. This is worse if the rebuild breaks something since someone will have to fix or revert that before it can succeed.

For non-security updates, they can do the rebuild in a branch (staging) so it's non-blocking, but you will feel the pain on a security update.

In practice, users will apply a config mitigation if available or "graft" executables against an updated lib using system.replaceDependencies, which basically search and replaced the built artifacts to use a different file path.

This was seriously proposed by some. E.g. "scaling services independently"

Scaling services independently is usually a recipe for outages where something is at the wrong scale. Sometimes you want to separate workloads that don't fit the request response model well because they take too long or use too much CPU or RAM, but you don't need micro services to get that benefit.

I don't think anyone was claiming it would lower latency for typical requests except maybe indirectly through materializing views in event-driven architecture.

I think the steel man has been about scaling teams, but the discourse was not limited to that.

E.g. "Acquired" tends to have this since both co-hosts research the same topic. I think they try to split up the material, but there is inevitable overlap. They have other weird interactions too, like they are trying to outsmart each other, or at least trying not to get outsmarted.

Some podcasts explicitly avoid this by only having a single host do research so the other host can give genuine reactions. E.g. "You're Wrong About" and "If Books Could Kill".

Basically all early stage startups use ISOs. Public companies typically use RSUs. Some startups transition to RSUs before their IPO.

RSUs are kind of unworkable if the valuation will increase significantly before the shares become liquid since you owe taxes on their value as they vest whereas ISOs let you defer taxes until at least exercise if not sale.

This is has actually been used before.

Ports would tax ships on the value of their cargo. It wasn't viable for the port to create valuations themselves, so they left it up to the ship, but the port had the right to buy the cargo at that price.

The scheme kind of works well if it's liquid commodities (e.g. grain, oil, lumber) and the purchasing right is held by a non-capricious authority (i.e. one that only exercises that right to call a bluff).

Taking a down-round on an IPO can be very damaging to a company. Since employee equity is based on options, that puts those options underwater and means employees will make nothing in the IPO. Internally, the company is doing 409a valuations and admits in writing that the valuation is down.

Similarly, I wonder if nyxpsi has congestion control? It's probably tricky to implement if you are trying work with a crap network. I guess you could see how packet loss or latency responds to throughput, but then you need to change the throughput periodically while transmitting, which slows down the transfer.

Turning off fsync is pretty dangerous since a crash could corrupt the database. You might think you would just lose a couple seconds of data, but that's only true if writes are applied in order.

E.g. if some data is moved from page A to page B, you normally write B with the new data, fsync, and then write A without the data. Without fsync, you might only write page A and you would lose that data. This might happen on a internal data structure and corrupt the whole database.

Otel works as a standard since there isn't any need to innovate at that level. Despite the over complications it has, all the implementations largely have the same requirements, and it's useful to instrument everything the same way.

Querying unfortunately has lots of room for innovation, and it's really hard to nail down in a spec especially when the vendors all want to compete.

I recommend reading the filing since the DOJ isn't saying this.

The main differences is that RealPage collects and digests nonpublic information among competitors.

The DOJ also has a lot of evidence that RealPage knew that this would increase prices and prevent competition.

RealPage itself is also a monopoly. There are strong network effects with the service, and RealPage's willingness to allegedly anticompetitively raise prices means a another more scrupulous competitor is unlikely to succeed.

I also wasn't there, but I think this actually wasn't to help authors and instead was a workaround for the warts of SQL. It's a pain to write

    SELECT * FROM (SELECT * FROM ... GROUP BY ...) t WHERE ...

and they decided this was common enough that they would introduce a HAVING clause for this case

    SELECT * FROM ... GROUP BY ... HAVING ...

But the real issue is that in order to make operations in certain orders, SQL requires you to use subselects, which require restating a projection for no reason and a lot of syntactical ceremony. E.g. you must give the FROM item a name (t), but it's not required for disambiguation.

Another common case is projecting before the filter. E.g. you want to reuse a complicated expression in the SELECT and WHERE clauses. Standard SQL requires you to repeat it or use a subselect since the WHERE clause is evaluated first.

In the query plan, filtering before or after an aggregation is the same, so it's a strange quirk that SQL requires a different word.

You probably want to use LATERAL JOIN, which will compute the subquery for each left hand row. Otherwise it's computed just once.

I do the same, and the only leak was target giving my email to a pork-related class action lawsuit.

Transactions cannot compose because nested transactions cannot simultaneously (1) ensure committed transactions are visible and (2) uncommitted transactions are not visible.

If you don't care about visibility until the end and just want nested atomicity, you can use savepoints as a kind of nested transaction, but they won't be visible to other sessions until the top level transaction is committed.

CREATE INDEX CONCURRENTLY has steps where it needs to make changes visible and wait until no transactions are open from before that point, so it can't use savepoints.