pravus

> Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?

Any bit changes anywhere in the merkle tree immediately destroy its ability to self-verify because the integrity is ruined. Basically the entire tree is dead because you can't add new nodes.

Non-cryptographic file systems? A bit-flip changes 1-bit in an isolated place. That one place is ruined but can be easily recovered with checksums or strategies like RAID parity. Detection is harder, though.

Either can be recovered at the block level, though.

I use merkel trees as a solution for a project at work and it has brittleness issues related to data integrity and we have to solution specifically around it.

> If a judge ordered you to unlock your phone and hand over all your messages, you’d probably be sour but you should also be morally ok with complying.

No. It is not my moral obligation to obey the orders of other human beings. Ever.

If you want this to be a moral issue you must first prove that there is a moral basis for compliance and I've yet to hear one. Pointing a gun to my face and telling me what to do doesn't sound moral to me. You can ask. Nicely.

Much of the land in Texas is privately owned so you don't have many of the same issues in other states where there are arguments over where to build. It's a very easy decision for land owners in Texas because they get paid monthly per tower in operation. If you drive around Abilene and a little out southwest of there you'll see red lights at night everywhere and you can just count the cash-flow.

Oil is Texas "T", but money is always the real motivator.

No, this is different.

What you are talking about are things like bump keys which exploit known physical limitations in those types of locks in general. There is no way to fix this other than switching to an entirely different internal mechanism.

What is being discussed here is the intentional disabling of existing security features within a locking mechanism which further reduces its effectiveness. This is regardless of the effectiveness of the class of lock overall.

An example would be going to the hardware store and buying a 7-pin tumbler lock but only 5-pins are installed. Yes, all tumbler locks are vulnerable to bump keys but an additional hidden (and fraudulent) act was performed which further compromised my wishes for a "more secure" tumbler lock.

In the case of cryptography, the locks are much stronger and there is vastly more at stake so it's important not to be too casual with the analysis. The 'fix' is to remove all doubt that any such malfeasance ever took place.

> Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended.

One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos.

Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible.

I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.

The logical end-game of direct democracy is the death of Socrates.

I generate children faster than the birth registry can issue certificates and Cronus eats them before it could be issued anyway. Nesting namespaces doesn't solve the problem of scale within a single namespace.

I'll also have the need to make namespaces dynamic and centrally coordinate their lifecycle along with the rest of my infrastructure as I stand up anything that needs some sort of coordinated ID. So I've just moved this issue to an even larger scope with even more complexity.

What do I gain for this? UUIDs solve all of this because the chance of creating a duplicate is so low it can effectively be ignored. I can namespace UUIDS and create chains of them if needed.

This is the reason both exist. We need both. We can use both.

> We can have registrars for global ids, and we can nest local ids inside them, we can have a hierarchy, and we can have local compact ids, 32, 64 or 128 bit, which will never collide, and be locally cohesive.

We have this. It's called OID (Object Identifier) and is used in X.509, LDAP, SNMP, and many other technologies. A global registry exists (I have an entry) and it's a giant tree.

> So why aren't we doing this? Is it ignorance?

The problem you are solving here is for durable, long-lasting keys. There is also a need to generate large batches of short-lived keys that need to never collide for security/identification purposes. A centralized registry will not work for that and it requires a wholly different technique.

> There's something just morally wrong about wanting to exist in an endgame society that decides its best to give zero credit to creators of ideas. > I refuse that and actually would go to war over it.

It is absolutely morally debased and corrupt to advocate violence to resolve intellectual pursuits. I want to exist in a society that shares ideas since they are not scarce and we can argue over the actually scarce things we care about.

Find what works for your body without doing anything that makes you hate life.

I tried the "eat less, exercise more" routine for two years straight when I weighed over 340 lbs. Calorie restriction and walking everyday. I lost 50 lbs but had to quit because I was no longer able to motivate myself to keep doing it because I was absolutely exhausted.

Switched to keto on whim because I basically said "let me find something nutritious for my body that I can eat every day and satisfies me". The only option for me was paleo-related stuff.

No exercise, no calorie counting and I lost 90lbs in a single year. I felt healthier, slept better, had better hair, skin and joints, and several people thought I had a disease I lost so much weight so quickly.

10 years in and I still do not count calories. Ever. I eat meat, dairy and protein with as little sugar and carbs as possible. I am never hungry. I eat what I want, when I want as long as it is low carb.

I now consider this to be a solved problem for me. I'm not saying keto is for everyone, but find what works for you. It will be obvious to your body when you do.

I use a technique I call "runtime comments":

  if false {
    ... stuff I don't want to run right now but the compiler still has to deal with it ...
  }

The only way to negotiate with animals is on their terms. When in Rome as they say...

> First, why do you even need HTTPS on a trusted network.

PCI compliance among many other regulatory issues. You will be required to show that data is not only encrypted at rest but is encrypted through your entire transport chain regardless of any physical security. The threat model assumes that an attacker is able to temporarily access network resources undetected and can use simple sniffing tools to egress sensitive data. This will not be optional.

My understanding is that the Higgs field should be simpler than gravity because it's just a static value whereas gravity is SU(1)? At least to me it seems logical that if the Higgs is quantized, surely more complicated fields would be as well?

It has worked great for me for decades and I currently stream live video over X11 on my LAN.

And no, I don't think the developers are incompetent, they obviously have different priorities than I do. Being able to shift an entire desktop environment over a network is something I've done since I started using the internet in various ways and I'll echo the sentiment that it seems incredibly useless to remove this feature in today's world.

To be quite honest I'm tired of this holier-than-though attitude. They dropped it because they are lazy or just don't want to support it and they should just be honest about that. They certainly didn't do it because it makes my life easier and I wish they would stop telling me I'm in the wrong.

> Yeah, please repeat the same bullshit for the umpteenth time.

I'm currently streaming X11 over my LAN which is something I can't do with Wayland. Give me a fucking solution instead of telling me I'm doing it wrong.

Yes, I'm tired of seeing all this bullshit, too. I'll switch immediately when Wayland gives me want I need to make me productive. Until then, I'm absolutely sick of this cocky attitude.

> C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug.

I guess because I just don't agree with this viewpoint at all. I've been writing C on and off for over 20 years now and I simply haven't encountered the amount of distress and pain that I see others deal with, especially when related to memory handling or undefined behavior.

I wrote a piece of software in Win32 C for a gas integration company many years ago that did tons of string manipulation to recalculate reports coming out of another piece of software. It even included a custom built on-disk database which basically ended up being my own version of BDB. Scratch that, I wrote this software twice because my first version was lost in a disk crash and I had to hex dump the database format to recover my original implementation.

Last I recall that software ran at that company for over a decade and probably helped them make millions in revenue. I didn't have a single support ticket and to be honest the last time I talked to the owner I thought they had just stopped using it. I was very surprised that they were still very happy with it and it was working fine.

That's just one of many examples of projects I've built or debugged in C. I've regularly been able to fix issues in OS drivers, large projects like Asterisk, and things like deadlocks in toolkit-based GUI programs. It's actually easier for me to use C than most other programming languages because it's clearer to me what should be happening, especially when dealing with anything systems-related.

That's just my experience. I totally get that others don't share that same experience but to be honest I'm pretty tired of seeing all of the confused hatred for C.

People take it too seriously and don't realize that you can't realistically categorize every single change neatly into 3 separate breakage categories. Arguments abound about how to manage this properly with all sorts of schemes. The fact that "0" is a special case that deserves any consideration is an example of it being broken, imo. What does it actually matter what the first digit is?

Version numbers just denote a change happened and you want them to roughly resemble some sort of chronological ordering. Everything else is gasoline for flame wars and company policies.

Any civilization that would use violence against non-violent offenders cannot be defined as advanced.

James Tabor released a translation of Genesis that has me very interested because he states that he stays as true to the original Hebrew meaning as possible and it reads completely differently than everything I've ever known.

They asked for the resource. You are free to give it to them.

I got tired of this sort of thing recently and now my web server returns 402 for everything that doesn't exist or has an invalid request. Most of what I do involves API and static data so I just serve everything from memory and avoid all disk access. It really bothered me that tons of stupid bots eat up resources asking the kernel for ENOENT.

URLs refer to resources, not files.

How did the URL not exist? An empty resource is still a valid resource and 200 is an appropriate response. You can argue that Prometheus has a broken data model, but the request and response are actually valid in my book.

> Weights are literally numbers computed as output. They are not instructions.

They are instructions if you consider the LLM system itself to be a kind of weird, indirect virtual machine. Each number can be mapped to a set of instructions that are executed. Even your CPU uses numbers (machine codes) to execute.

Join me in saying: ...code is data is code is data is code is data...

The problem is that a URL isn't actually a path. It's an abstract address to a resource which can be a directory or file (or an executable or stream or ...).

In this case part of the URL is being interpreted by nginx as a directory (http://localhost/foo) due to how that URL is mapped in the configuration to the local filesystem. Apparently it references a directory, so when nginx constructs the full path to the requested resource, it ends up with "${mapped_path}/../secretfile.txt" which would be valid on the local filesystem even if it doesn't make sense in the URL. Notice how the location of the slashes doesn't matter because URLs don't actually have path elements (even if we pretend they do), they are just strings.

This is a very common problem that I have noticed with web servers in general since the web took off. Mapping URLs directly to file paths was popular because it started with simple file servers with indexes. That rapidly turned into a mixed environment where URLs became application identifiers instead of paths since apps can be targeted by part of the path and the rest is considered parameters or arguments.

And no, it generally doesn't usually make sense to honor '.' or '..' in URLs for filesystem objects and my apps sanitize the requested path to ensure a correct mapping. It's also good to be aware that browsers do treat URLs as path-like when building relative links so you have to be careful with how and when you use trailing '/'s because it can target different resources which have different semantics on the server side.

Yay, more bolt-ons. Like I said, I left all this behind.

I didn't say they were correct. I said be aware of them.

From my perspective (over a decade of Perl programming now doing Go):

  * It has no concurrency primitives that are anywhere close to other popular languages
  * Tooling is good and works but is archaic, slow, and cumbersome
  * The community hasn't positioned itself to be anything other than lightweight backend services and small webapps (smaller than rails)
  * The community isn't really all that inviting or fun to be around

Basically Perl offers me nothing that Go doesn't. I'm just as fast in Go as Perl and it's much easier to get stuff done. It's sad because it has some really good features that I miss but I just rewrote a final project from Perl to Go and am never looking back.