adwn

They already are to many people. Maybe not to you, but that's okay — no tool has to be useful to everybody. It's therefore a valid assumption.

> CRT vector displays (Vectrex) to this day get better effective refresh rates, brightness, and glow effects than existing displays (OLED) and peaked in the 1980s

Except that they're absolutely huge and heavy for any halfway decent screen size and resolution. If I were to replace my two 24-inch screens with CRTs, I'd need a second desk for them alone.

Are you suggesting to plant trees in such a way that they can tap into the water stream they're meant to protect from evaporation? Doing the calculation on which of the two effects will outweigh the other would surely be a fun exercise.

Are you being intentionally obtuse? Try reading their comment in its entirety, and not just as individual fragments taken out of context: They most likely didn't have the budget to hire a professional designer and no one else would do it for free, so they had to do it themselves. They didn't enjoy it, and they would've gladly passed that work to an AI, had one existed back then.

It's not that hard to understand. Here, I've linked it for your convenience: https://news.ycombinator.com/item?id=49765890

They said: "I volunteered and designed a good amount of posters for student organizations." What do you think how many student organization have the excess money to hire a professional designer for a one-off poster? Of course they needed someone to do it for free, or else it wouldn't have been done at all!

No, that's a myth. It's true that the instruction decoder in a CPU core translates from ISA opcodes to micro-ops for the backend, but those micro-ops are in many cases functionally very close to the ISA instruction and decidedly not RISC-like. For example, the ADD r/m64, imm32 instruction (read from memory, add constant, write to memory) is translated to a single micro-op on several Zen architectures [1], which is far from anything you could call "RISC".

[1] https://uops.info/html-instr/ADD_M64_I32.html

Russia wants an excuse to justify mobilization in Russia, not in Europe.

> Norwegian state through its participation in NATO murdered millions of people in the middle east

I'll file this under "blatant lie" unless you can provide at least three reliable sources for your claim.

Both the world's population (with 88% to 12%) and landmass (with 68% to 32%) favor the northern hemisphere, so it makes sense to favor it in a general map as well.

A plastic bag protects against water and dirt, and it has handles for carrying. I'm not necessarily defending the practice, but it has its reasons.

Please elaborate. Where does my comment leave the "right direction"?

> they just want volunteers for the hard-to-staff weekday shower-cleaning shift

This may sound like a loaded question, but I assure you, that's not my intention. If you want to provide for those "invisible" homeless, who aren't drug addicts or mentally ill, shouldn't the primary volunteer pool consist of exactly those invisible homeless people? Or in other words, once you have organizers, why do you need external volunteers for cleaning the showers?

This attitude, if followed without qualifications, is dangerously naive and shortsighted, as the last few years of geopolitical events have shown.

Off-topic: I have absolutely no idea why my comment got downvoted. I shared a personal anecdote that's directly relevant to the discussion at hand and which counters the claim of the comment I replied to. Does someone think I'm lying? Was my comment too controversial? I don't get it. What is wrong with this site?

> […] I don't think anyone who grew up in a bigger family under one roof could agree with that.

I do. I grew up with 5 siblings, and having brothers and sisters is very, very different from having your own children. My relation with and my emotions towards my children is very different from my relation with and my emotions towards my siblings, both now and when I was still living with them in the same house.

> The idea being that getting your tokens from Provider A is no different than Provider B, especially if they both offer the same model.

You're describing a commodity. However, the commodity isn't the tokens, but the compute capacity, i.e., serving a model. And compute capacity isn't a currency — at least not, until you can acquire compute capacity from one party and exchange it with another party.

dgellow is absolutely right: tokens aren't a currency, nor can you trade them, nor are they fungible. The original claim that "tokens are just a type of currency" [1] makes no sense.

[1] https://news.ycombinator.com/item?id=49364984

> Step 1 could be not turning the world into a an Orwellian nightmare and outlawing mass surveillance, from both government and private corporations.

That would make society better, I agree, but I don't see how that would lead to a reduction in theft, or crime in general.

> And if you are still worried about theft in the mean time, you could try looking at wage thefts […]

I'm not worried about wage theft, no. I am worried about theft of my personal property, though. And I notice that you haven't proposed any credible path to reducing it, beyond an incredibly generic "make society better", whatever that means and however you want to achieve that.

> Theft is solved by making society better, not worse.

Phew, good to hear. Here I thought it would be a hard and complex problem, with lots of unknown unknowns, difficult political compromises, a generation-spanning efforts and many potential solutions with uncertain outcomes, partially contradicting each other.

Instead, we just have to make society better. So, what's step 1?

For pondering trolley problems, maybe?

> You just listed examples of unbounded lifetimes.

You're just splitting hairs and trying to weasel around the fact that yes, you really can create any lifetime you want using unsafe.

> Not sure what you meant by this example since it doesn't compile.

That's because the crappy HN formatting ate some of the characters. Here's the original version:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

> What you probably meant is […]

If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"? In your playground link, you did effectively disable the borrow checker in safe parts of the code. Next thing you're moving the goalpost, now it's not about external, static analysis tools: "run this with UBSAN, ASAN, and other C tools". I don't think you're arguing in good faith here. Goodbye.

Please try to interpret comments in the context of the discussion, not floating freely in a vacuum. The context of the discussion is the Bun port's excessive use of unreviewed unsafe blocks. unsafe in Rust can easily be misused to create Undefined Behavior, which renders any safety guarantees otherwise ensured by Rust's borrow checker invalid.

> Does bun actually do anything insane like that in its unsafe blocks?

Who knows? At 10k unreviewed uses of unsafe, I'd guess there are quite a few incorrect ones. LLMs don't produce perfect code (neither do humans), so there's a high probability that at least some of those create UB.

> The only thing unsafe does is let you have an unbounded lifetime.

No, you're wrong: You can create any lifetime. Proof:

    fn oof<'desired>(x: &u32) -> &'desired u32 {
        let ptr = x as *const u32;
        unsafe { &*ptr }
    }

This will take a reference and return it with any lifetime specified by the caller.

> You don't disable anything.

I said "effectively disable". For example:

fn trust_me_bro<'a>(x: mut u32) -> &'a mut u32 { unsafe { &mut x } }

    fn main() {
        let mut x = 1_u32;
        let reference_a = &mut x;
        let reference_b = trust_me_bro(reference_a);
        *reference_b = 2;  -- Whoops
        println!("reference_a: {reference_a}  reference_b: {reference_b}");
    }

After the call to trust_me_bro, two aliasing, mutable references exist simultaneously. This would usually be prevented by the borrow checker, but the unsafe code has effectively disabled it.

"Fun fact", it lets you largely circumvent the borrow checker by creating arbitrary lifetimes: https://news.ycombinator.com/item?id=48974824

True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.

Let me guess: you know that it's literally true because everyone repeats it, right?

People repeat that figure of speech because it's a meme (in the original sense of the word), not because it's unconditionally true.

Those systems you're alluding to received ungodly amounts of work and resources, vastly more than most projects can ever hope for, and yet they're still full of holes and security exploits. You're unwittingly making a great argument against using C, C++ – or Zig.

Are you sure about "rms types" specifically? Stallman is very ineffective in his proselytization, owing to his complete refusal of any kind of compromise or concession to dissenting positions. This stance may keep your soul pure and righteous, but it won't bring you one millimeter closer to your objectives.

The human brain hasn't solved NP-hardness, either. We make it work using heuristics and automation tools, which in turn use heuristics themselves. I see no reason why AI wouldn't be able to take the same approach.

Solving the halting problem is neither necessary nor sufficient to prevent DoS attacks.

It isn't necessary, because settings timeouts or other resource restrictions works way better to prevent DoS.

It isn't sufficient, because even if you can prove that a program will halt at some point, this alone doesn't tell you how long it will take. What good does it do to know that the program will run for 10 years before it halts? By that time, service will already have been denied. Even turning hash table lookups from O(1) to O(n) (still very much terminating!) can result in a DoS.