This is always been the dumbest thing about "hidden volumes": It relies upon your adversary not knowing about veracrypt's hidden volume. Which BTW, is plainly ADVERTISED on the web site. The second he knows you have veracode, he will ask for the other encrypted volume.

See also relevant XKCD:

https://xkcd.com/538/

But Veracrypt can be used for encryption of a volume, without creating a hidden volume. I assume it would often be used this way.

The $5 wrench decryption technique would be even more unpleasant if you hadn’t created a hidden volume, as there would be no way to prove you hadn’t.

Should people be sure to never use Veracrypt volume encryption unless they create a hidden volume? I have trouble even thinking this way!

The $5 wrench isn't about breaking encryption. It's about breaking will power. If they achieve their goals great for them. If not they proved the second volume either didn't actually exist or your will power was stronger than the $5 wrench. Either way they're probably way more happy with the outcome than you would be.

As long as the border your crossing doesn't respect the 4th Amendment, the best approach is to not carry anything incriminating across it, nor anything that may make you suspicious.

Yes. And we are:

https://news.ycombinator.com/item?id=21237875

https://news.ycombinator.com/item?id=19845029

https://news.ycombinator.com/item?id=48783117

How does it deal with pointers if everything is stack based? You can't really return a pointer to something on the stack because it could get overwritten between when you return it and when you access it.

Exactly as well as C does, it seems.

    func newPerson() *Person {
        p := Person{Name: "Alice", Age: 30}
        return &p
    }

becomes

    static main_Person* newPerson(void) {
        main_Person p = (main_Person){.Name = so_str("Alice"), .Age = 30};
        return &p;
    }

Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling pointer or forgetting to free allocated memory. Most memory-related problems can be caught with AddressSanitizer in modern compilers, so I recommend enabling it during development by adding -fsanitize=address to your CFLAGS."

So saying you get the "safety of Go" is a bit of a stretch.

Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.

This is impossible. General words like "faster" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.

Whoa, I have my very first crazy internet stalker. What fun!

Do an internet search for "go garbage collector benchmark" if you're curious what the grownups are talking about.

That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C.

You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.

I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.

You're right, I misread their point, sorry for the pedantry OP.

Well, it does say:

"Everything is stack-allocated by default; heap is opt-in through the standard library."

So it supports both stack and heap, and I guess static allocation too.

I've been working on a SDN software for mikrotik routers (and wireguard, etc) and Fable dies when working with any kind of wireline protocol or potentially implementing any authentication mechanism.

It's too the point where I just stopped using it. If you do generic stuff, it's fine. But the second it tries to start debugging protocols (which may include auth) that's where it begins to fail.

I can’t even use it to fix the bugs Opus introduced. I’ve considered ripping out auth until fable is behind the paywall. I’ve been very careful in my queries and broken everything down to careful segments. Even the memory can get security verbs poisoning further requests.

Businesses have been anti-human for a while now.

If you think AI is bad, wait until I tell you about the horrors of social media who profit on controversy and division, US health insurance which profits on rejecting claims, and big pharma profiting on the opioid epidemic.

And it's not like this is new, either. Upton Sinclair was writing about this stuff a century ago with books like The Jungle.

The only difference between then and now is we "think" we're not evil today. We've lied to ourselves that "We're so much better than we were back then." Facebook wanted to bring people together originally, but they ended up providing the most toxic social media experience known to man. Facebook forgot to tell us they cared more about profit than people.

Please spare me the argument AI is the straw to break the camel's back here. The system has been broken a long time before that.

I have list of issues with SQL. Not composable. Unable to detect query errors at compile time because the schema is only loosely coupled to the code base. And as you yourself point out, SQL is not standardized, which is also terrible and leads to things like Oracle vendor lock in.

And frankly this list hasn't changed in 30 or maybe 40 years now.

And DBA's were so notoriously egregious that Martin Fowler made his "NoDBA" blog post over a decade ago now. And the movement to NoSQL definitely made things worse.

I wish the SQL community would stop treating ORM's like the vietnam paper did 20 years ago, and embrace them for what they are, as a stepping stone, and maybe as a useful tool to help people understand SQL itself.

> as a stepping stone, and maybe as a useful tool to help people understand SQL itself.

But that is not what ORMs are. They teach bad habits that make SQL harder to understand, not easier, because the power of SQL depends on good data modelling.

Perhaps the worst habit is treating the database as subservient to the application code. This assumption comes naturally to many programmers. In most programming contexts, file formats, wire protocols, and internal representations are defined by the code that consumes them. That's fine in some cases.

But in a data-centric application, the relationship should be reversed. Before writing a single line of application code, you should understand the domain model and design a schema that represents it well. The database is not just a persistence layer for objects. It is the system of record, and its structure should reflect the shape, constraints, and relationships of the real-world data. Everything else should be built to conform to it.

I mean there are plenty of projects that don't fit this description, where the database is just a persistence layer for your objects and the database should be subservient to application code.

In amateur radio there was a famous DXpedition there this year.

https://3y0k.com/

There are some videos on facebork but you have to trade your data to see them apparently.

Alternatively there's some pictures on this page, so you can get the idea of the remoteness and weather they have.

http://ict-kuwa.net/3Y0K/latest%20news.htm

More likely they'll convince congress they will need their own. Only it will 20-200 times more expensive and the US taxpayer will be paying for it but won't get access.

That would meet the OP's goal of NSA never getting a frontier model, "behind schedule" is the natural partner of "over budget".

Honestly, I think the biggest enjoyment I got from this thread is that programming culture is often toxic in ways that people aren't really ready to admit on this site which is dedicated to computers and programming.

I can hear them now: "Surely, you can't be happy with your decision, Mr. Ralo. You're leaving so much money on the table!"

And you're saying calmly: "Yes, yes I am."

Best of luck to you and your efforts.

I've tried both. I've seen what both offer and I'm so confident in my decision that I just sit back and watch the gong show at this point.

My decision gets further cemented when I ask my tech friends how work is going.

I just downgraded the skillset needed and moved back down to dedicated IT. It's so much easier and I have zero job-related stress 95% of the time. I already worked a flashy job with big name recognition. I don't need to prove anything to anyone. I want no extra hours or responsibility. It's great.

Have you thought of opening your own truck repair shop? Often there are places where trucks break down and the solutions are slim to None. A good repair shop in the right place might make decent money.

I'm so at peace right now, the flow is good. I don't need the hustle of chasing mllions of dollars. The owner of the company can deal with that, I just want to do my 8 hours and go home free and clear.