singron

Concurrent index creation internally uses multiple transactions, so it can't itself be wrapped in a transaction.

The docs explain the mechanics further: https://www.postgresql.org/docs/current/sql-createindex.html...

In the origin legend of the marathon, the runner dies upon completion.

The original Sherman Act specifies imprisonment for 1 year, a $5,000 fine, and the seizure of property due to the violating behavior. It also gives courts the authority to "prevent and restrain such violations". It makes no specific note of splitting up corporations.

Obviously this isn't the modern understanding, and the act was later amended.

In a very competitive market, reducing quality slightly could drastically reduce revenue.

E.g. if there were two brands of apple at the grocery store and one started putting a tiny worm in each apple, you would expect the worm apples to lose nearly 100% of their revenue.

Panic=abort is more like -fno-exceptions since it applies to all the code being compiled and not just function. Codegen can also take advantage of the fact that it won't have to unwind.

I don't think there is a rust equivalent of noexcept.

As long as they aren't so disinterested that they become absentee leaders. It's rare for huge successful projects you've heard of, but I think the typical project is more likely to have this problem, although maybe it's just incompetence too.

This doesn't make sense. It sounds like reddit made the appropriate robots.txt changes, and Microsoft is respecting them. But the quote is representing that reddit is taking some action beyond that to effectively block Microsoft.

> He specifically named Microsoft, Anthropic, and Perplexity for refusing to negotiate, saying it has been “a real pain in the ass to block these companies.”

Surely updating robots.txt isn't the pain in the ass he is referring to?

"SIMD Within A Register"

I think the implication is that you can pack multiple items into an ordinary register and effectively get SIMD even if you aren't using explicit SIMD instructions. E.g. if you pack a 31 and 32 bit number into a 64 bit register (you need 1 spare for a carry bit), you can do 2 adds with a single 64-bit add.

Games have used these tricks for graphics to pack RGB(A) values into 32 bit integers. E.g. this code from scummvm interpolates 2 16-bit RGB pixels (6 total components) packed into a 32-bit value. https://github.com/scummvm/scummvm/blob/master/graphics/scal...

Do you have a commercial interest or is this just for fun or a kind of public service?

Google also stopped using Gmail for ad targeting.

You can listen on an anonymous port. It's similar to how the kernel allocates a port for outgoing connections. It's very useful if you want to listen ephemerally, especially in tests. The downside is that you need your server to report which port it's actually listening on, and if it restarts, it will get a different port.

This is only 1 disk, so you are way more likely to lose all your data due to an ordinary single disk failure than to some ram errors.

If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.

E.g. this godbolt: https://godbolt.org/z/eMYWzv8P8

There is unconditional use of a pointer b, which is UB if b is null. However, there is an earlier branch that checks if b is null. If we expected the UB to "backpropagate", the compiler would eliminate that branch, but both gcc and clang at O3 keep the branch.

However, both gcc and clang have rearranged the side effects of that branch to become visible at the end of the function. I.e. if b is null, it's as if that initial branch never ran. You could observe the difference if you trapped SIGSEGV. So even though the compiler didn't attempt to "time-travel" the UB, in combination with other allowed optimizations (reordering memory accesses), it ended up with the same effect.

From my memory, extremely large but semantically simple changes still used global approvers since it wasn't considered worth the effort to get approval from hundreds or thousands of individual OWNERs using rosie. Also, with a change of this magnitude, especially one affecting BUILD files, it might not have been possible to create the mega-CL that rosie uses, but I don't remember specific limitations on that.

This is not a valid interpretation of this case. The judge concluded that the employer fired the employee in retaliation for union activity. The company claimed they fired him for lying on his resume, but they couldn't prove that was the reason (which is their burden to prove), and it wasn't consistent with prior company behavior. E.g. they had a recorded conversation about how they could figure out a way to not hire a union applicant, and they had never fired anyone for a similar infraction before.

Importantly, the only detail on the resume that was false was the name of the prior employer. They had accrued the same experience at a union employer instead. This case doesn't allow you to arbitrarily lie on your resume in order to salt, and you can still fire someone for lying if you can reasonably prove that.

You can measure "bloat" in the index. It's essentially the wasted space in pages.

You can also have bloat in the heap for the same reasons.

You may also want to cluster if your pg_stat.correlation is low since that indicates your heap isn't in the same order as your index anymore. pg_repack can do all of this without blocking, but you can reindex just an index concurrently on version >= 12.

https://wiki.postgresql.org/wiki/Show_database_bloat

Specifically, kill()ing pid 0 kills every process in the process group of the calling process. Pid 0 is more like a NULL pointer. You can put something in memory there, but a lot of systems will treat it as an invalid identifier for their own purposes.

I had some ruby code that called kill(str.to_i) and killed every process when the string wasn't an integer, which is when I painfully found out that to_i returns 0 on invalid strings and kill(0) kills (potentially) a lot of processes.

i3 is just a window manager. It's not a UI toolkit. It doesn't control how apps render UI.

GTK and QT are UI toolkits and do control how apps render UI. Your apps will use GTK and QT even if you use i3 to manage the windows.

You might be confusing GTK with Gnome and QT with KDE, each of which has its own window manager.

How do you measure without the API?

These are really interesting cases, and the opinions give a lot more detail.

Midler v Ford: https://law.justia.com/cases/federal/appellate-courts/F2/849...

Waits v Frito-Lay: https://law.justia.com/cases/federal/appellate-courts/ca9/90...

One interesting thing is that these cases are really deep in common law. They are quite far removed from statues, and statues are cited in the opinion only to argue how they don't apply.

In these cases, the voice was "distinct", and they intentionally copied it. It's possible these don't apply to ScarJo, although the fact that they negotiated with her is a bad sign, since that was also a common fact in the prior cases.

If you care, you can use a wildcard cert. E.g. instead of getting a cert for foo.example.com, get one for *.foo.example.com, and then use an obscure subdomain. AFAIK, nobody is bruteforcing subdomains on wildcard certs.

I took a closer look, and it looks like the compression doesn't depend on the seed at all. This makes it look like any collision is a collision on all seeds.

    pub(crate) unsafe fn gxhash(input: &[u8], seed: State) -> State {
        finalize(aes_encrypt(compress_all(input), seed))
    }

For a hash table, you would normally use just the low bits to select a bucket, so this still protects you from collisions on just a subset of the bits, but if you can produce a large number of collisions on the exact 128-bit output, then it's not DOS-resistant.

Can you realistically create fixed-point collisions of a randomly seeded hash function? E.g. to defeat the DOS-resistance of a hash table? I think the papers on fixed-point attacks of Davies-Meyer hashes require selecting the IV or knowing the IV in order to carry out the attack.

Also it looks like they don't (yet) have a copyright assignment, which would make it exceedingly difficult to relicense if they got significant external contributions.

There is a tax exemption on your first 250k of capital gains when you sell your house. The interest on your mortgage is tax deductible. If home prices increase 10% each year, then you can maximize earnings by moving to a more expensove house every few years.

In this way, your home is like a leveraged tax sheltered investment, and the limits are much higher than an IRA.

The offset from epoch time is probably unique per device per boot, and it only drifts one second per second while the device is suspended.

You can get the time zone from less naughty APIs, and that has way fewer bits of entropy.

The linker is a convenient way to get your code to run in the right place, but the linker runs in userspace, and your code can do anything the linker does. E.g. you can scan function tables, remap pages r/w, and interpose functions.

The OpenBSD folks have some good ideas against these issues, although they are targeted at things like ROP exploits. E.g. pledge, which disables certain syscalls, and immutable memory maps (https://marc.info/?l=openbsd-tech&m=166203784715942).

A really scary version of the xz backdoor is if it had an entire implementation of openssh in its own ctor function. Then it wouldn't even need to interpose anything. It's way harder to get rid of ctors.

People are confusing the limited computational model of a transformer with the "Chinese room argument", which leads to unproductive simultaneous debates of computational theory and philosophy.

I have no specific knowledge, but it seems similar to issues we had before iommus. E.g. maybe the device accesses physical memory without memory protection and/or virtual address mapping, so the kernel needs to do that in its behalf.