gnull

> Don’t Swedes just rent them out on the black market instead?

They do (with obvious drawbacks of anything illegal). And the black market prices are awfully high.

> If we made it much much easier to build housing then then rental housing market would be like the used car market: viable but not an easy place to sit back and make passive income.

You're overthinking it. Sweden made renting out apartments unattractive without all this sophistication, they just regulate the prices and keep them low.

If your equations are in MathML, the browsers should be able to screen read them at some point.

> Even slight differences in layout can make a complex set of equations difficult to parse.

Such set of equations should normally be represented by a single block, I can't imagine a reason why layout should change inside that block.

The layout of pdf is unnecessarily rigid. When I'm reading it on my screen, there's no reason the text should be split into A4 pages with very specific margin values. Latex also often moves your figures a few pages ahead because they didn't fit on the specific page. There's absolutely no reason for that when you have access to the big continuous canvas of an html page. This works for equations too; if you have a long equation block that happens to be right between two pages, you either have to let one page have a gap, or reorder/rewrite your paragraphs to make the equations fit. None of this has a good excuse when it's read on a screen.

I don't think we need a website, but a js-free webpage with hyperlinks would be a lot better than pdf. Pdfs I find imperfect but ok.

I'm not saying this way of gathering people's opinions is completely useless, but it has big flaws. Being against this sort of feminist initiatives can get you labeled all sorts of things in the best case, and cancelled in the worst case.

It's like making a poll in Russia about whether citizens support the invasion of Ukraine or not, when saying you don't like it is a criminal offense that can get you in jail. "I just went out and asked some people on the streets of Moscow whether they support bombing of Ukraine, nobody said no while a couple of them said yes, so they must really like that."

> which most people hated and voted against

Was there voting about these things? Who got invited to vote?

You mean calling the adversary Mallory? Yes, this is standard. The term mallory-in-the-middle is not, as you can confirm with one Google search. There's barely anyone using this term, and nobody was using it 4 years ago.

At first, I thought that Mallory-in-the-middle was some special type of man-in-the-middle attack. In crypto, Mallory is a very specific type of adversary (active one, I think).

I was sure it's something else, never heard of this being a standard term. Google search gives me only movie characters, "name meaning" pages, and a project called "Mallory in the middle" that implements some specific man-in-the-middle attack.

I guess it's another case of those "raising awareness" changes, that is supposed not to cost anything, but just made me spend like 4 min confusedly googling what the new term means.

> It is common among secure messengers to require out-of-band verification to protect against active mallory-in-the-middle attacks.

What is Mallory-in-the-middle?

EDIT: It's the same as man-in-the-middle. Author's explain this when they first mention MiTM.

Also you need to identify the monitor somehow for kernel to do what you propose. If your monitor setup is not static, say, you connect monitors in different order or through different ports each time, you won't be able to tell which edid should go for which monitor. (Unless you're willing to script some heuristics to guess that.)

The main problem with the naive solution is not the overflow, but the undefined behavior caused by it in C.

If overflows are allowed, like in Rust, you could implement this by representing X and y with two ints each and doing mini big integer arithmetic on them.

I must admit though that I've spent quite a lot of effort on playing with types that time, and often neglected carefully designing the architecture of my program and the way I'm applying lenses there, which made me regret it later.

It may be a matter of experience. I probably would not be able to use them during my first or second year of slowly learning Haskell, but later when I learned to naturally think in terms of functors, applicative and traversables, I just sat down and used them.

A lot of the time when I couldn't completely untangle some type definition in lens library, I'd just go with gut feeling or guess what it does by analogy with stuff I already understood, and surprisingly often it compiled and worked like I expected.

I found Hoogle very useful for this guesswork.

Making good coffee needs to be done manually, you gotta put your soul into it. Where's soul in GitHub actions?

Is Kakoune mode anywhere in sight?

I have a really hard time following anything you say here.

How did we start talking about Java and VMs? Is this some sort of strawman argument?

> But sure, the more complex a system becomes, the more contemplation it requires to figure out problems

Strawman again? I wasn't talking about complexity. I said that the more "systems" your programming is, the higher is the cost of memory safety bugs.

I still don't understand why would you prefer raw memory manipulation to bytestring manipulation. If you want, just make a Swift library that will implement the memory like you want but without unsafe raw access (but just a few methods over a byte array). Back in the days when I did CTFs, I used Python for writing binary exploits, never C.

https://github.com/hellman/libformatstr

You can do something like this, no need to work with raw memory.

Is this a joke? Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts, and managing memory as you said.

If you write in C and your program is complex enough, you will spend a lot of time just chasing segfaults and concurrency bugs and getting it to work the first time you write it. If your systems programming is in userspace, that's sort of fine. But if you're in kernel or on bare metal, the cost of debugging goes up by an order of magnitude. There's no debuggers on bare metal, and nobody can tell you how your program crashed—the device just stops responding, that's it.

That's why safe languages make even more sense in these restricted environments. If you get twice fewer memory safety bugs while you're getting your program to work, that can reduce your development time like 5-6 times.

You mean, manipulating strings of bytes? Bytes don't have to be memory, you can just use bytestrings in Python or whatever.

Raw memory access is something you normally need to create vulnerabilities, not to exploit them :)

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle

This says more about those C++ defenders.

Alpine base rootfs is just a few megabytes, while Arch is like 100-200MB. I usually encounter Alpine in Docker containers when people want to wrap just one specific service and have save space on things that are not essential for it (it would be wasteful to ship your 20MB app in a 200MB Arch/Debian container).

I didn't know Alpine was useful as a working machine though.

Thanks for the clarification!

> The Barentsburg Pomor Museum presents Pomor culture, Arctic flora and fauna, and archaeological objects preserved in the permafrost.

Wow, this is hardcore. Wikipedia says that Russian Pomors reached there around the same time vikings did. (Pomors are Russians who historically lived far North.)

> Browser not supported. Please use a chromium based browser instead.

I see this in Firefox.

Evolution is working fine with the setup I described, try it out if you need to do this again.

It works fine, unless you want to use Google Calendar and a non-Gmail email together. Then it goes nuts and makes your Gmail send out calendar invites instead of the email you use.

Don't governments allow it when it's done under supervision?

Sorry, I indeed switched to a wrong browser tab and skimmed instead of reading when started this discussion. Please disregard the quicksort discussion.

I still think that it's normal for programs to behave weird when the input parameters are getting close to INT_MAX. Sometimes it's unavoidable. And if it's not specified in the function docs, you should go and check the implementation as a programmer. For binary search it is avoidable, so the criticism of the linked implementation is fair.

No, wait. The QuickSort from the article is O(n²), in fact. So that one specifically will take weeks, or even months to run — especially in Java. Feel free to test it and get back to me if you think I'm wrong.

Ok, I looked at it closer and I admit that quicksort implemented in C won't take days on an input of 2³¹ elements. It will take less than 1-2 hours, I think. Something that is a bit worse than O(n log n) or has a 20× bigger constant hidden in O(·) will take days though.

I don't see my other arguments being convincingly refuted, so they still hold.

> most binary search implementations don't claim they only work under some particular inputs

They do implicitly. It's just common sense. When you read a recipe in a cookbook, it usually doesn't mention that you're expected to be standing on your legs, not on your arms. Reader is expected to derive these things themselves.

A lot of generic algorithm implementations will start acting weird if your input size has the order of INT_MAX. Instances this big will take days or weeks or process on commodity CPUs, so if you're doing something like that you would normally use a specialized library that takes these specifics into account.