I’m sorry to hear that your iPod might be bricked. I haven’t worked on an iPod gen2 personally, but I repaired an iPod mini. The interface for the small hard drive in that is the same as compact flash, so it’s very easy to replace the storage with something more physically durable. Or at least it is easy to find the replacement part - I haven’t tried the whole process on your iPod.

Not on nixOS, but I thought I would weigh in on my preferred value for swappiness. 0. For some reason when I have a month of uptime (and I suspend once a day), doing anything with the desktop environment for the first time in a few hours causes a micro stutter for maybe 100ms, as if having to swap out from disk. Turning swap off and on again (meaning no pages are swapped to disk anymore) immediately fixes it. Opening a new tab, pressing the super key even performing certain actions in a video game cause the stutter. I know the internet tells me that 0 isn't a good value, but my computer becomes noticeably worse to use even with a swappiness of 5. I have enough RAM for anything I want to use this computer for, so swap is just for suspend for me.

Agree. I tried using a swapfile last year-ish, as the internet experts tell you to. I have 64GB of RAM. If I fresh boot and start a few apps I'll be using maybe 16GB RAM + 0GB swap. Then a few hours later I see I'm using 8GB of RAM + 8GB of swap... why? Why did Linux waste IO moving data to disk when there's no memory pressure?

That's why I don't use swap.

Generally the idea is that regions of memory that aren't being used are swapped out to disk, then other more useful things are brought into memory.

For example: you have a background program that you're not using and in the foreground you're crunching data from disk. In this scenario the most efficient use of your memory is to swap the background program out and pull the disk data into RAM.

It's a broken idea, throughput über alles isn't true of an interactive system, latency matters. There's a calculator app I use every now and then. Linux always thinks it's a good idea to swap it out since I'm not using it all the time, which means that every time I want to calculate something there's lag as it's swapped in again.

Another aspect I'd wonder about for relatively simple tasks is just freeing it from memory and being prepared to pay the cost of loading it again, it's probably already on disk. Latency matters, but it seems there will be limits especially considering the transfer speed and latency improvements we've seen to storage commonly installed in most systems over the past 15 years or so.

Then comes the challenge of deciding what processes/data to free or page, whether that's flagged by the system as it's running or at coding/compile time. And that seems similar to the issue of picking a swap strategy for a distro/OS, which will depend on the user's demands or system, setting a good default and exposing how to change the configuration to a better match if needed.

No sorry, its not a broken idea: throughput über alles is true of high-throughput-demanding systems, but latency matters is also true, for latency-demanding systems, and the two use cases represent - in an industrial sense - a very vast array of values. It's not really either/or - you are indeed identifying a knob that needs to be turned, in your particular use-case, on your particular system. There is no one-size fits all: it's a knob.

But why should it swap things out even when I'm not crunching data and there's no memory pressure? I'd rather everything stay in memory and stay fast, since I have enough RAM.

Maybe not what's happening in your case, but stuff that is in swap will not be moved back to memory unless there's a need for it, so if you did have memory pressure at time 1, which resolved at time 2, then you might still see a lot of swap in use at time 3.

Your distro may vary on the policies around this, but the way the stack generally works, is that whatever shared libraries, and their memory resources, which haven't been touched in a while, are put into swap. So if you've run a few programs, left them open or whatever, switched the UI to other things and whatever over a period of a day, or even a few hours/minutes (its a knob), then bits of those programs will have gone cold. The local libraries and static things that haven't been executed - in a while - will move into that qualification.

You can tweak this, it is indeed a local-system configuration thing that a Linux user should know and think about - and maybe - if your distro has such a thing as a policy about it - this ought to be considered as well.

For example, I use Ubuntu Studio, precisely because it is generally well set up, swap-wise, to absolutely not interfere with audio performance (note: this DAW has been rock solid for decades) .. but every distro has its own 'medium ground' to consider when setting this.

The thesis/antithesis for/against swap is un-useful. Swap is a knob, not a switch.

I suspect the intent is to move stale things out of RAM so it can be immediately used for more productive purposes when needed.

Shuffling out 8GB with a spinning hard drive could take a full minute…

That said, I agree with you. I’d rather not use swap unless absolutely necessary and I don’t want the latter to happen either…

Plus, I don’t want my storage in the “critical path” of memory accesses, even if rare.

Use swap for the important things: the part of your operating system at run time which doesn't get used much, but needs to be around when needed - the contents of /lib and /usr/lib and so on, all the *.so's and the things they allocate - shared libraries among the distro install, these things can be tidily swapped, until you need it.

If you need an application to always be responsive, start it with the swappable flag turned off, i.e. something like this:

    $ systemd-run --user --scope \
    -p MemorySwapMax=0 \
    -- /path/to/my/program arg1 arg2

Anyway, this is a distro-originated knob which every user must tweak for their use-case.

> I suspect the intent is to move stale things out of RAM so it can be immediately used for more productive purposes when needed.

These are separate problems, though. You can clean a page by updating its backing store without purging it from memory; and purging a clean page doesn’t require a write. It’s definitely reasonable to take advantage of idle IO resources to clean dirty pages, but pages should only be purged (clean pages first, usually) when there’s an immediate need for them for something else.

Is this considering RAM for disk cache too?

Did you ever try to ask a chatbot to rephrase your hint in its own words? If it prefers LLM generated text, surely that would help.

This is very similar to how you rewrite queries so that similarity search works better... which ... well, it's similarity search all the way down pretty much.

All of my gamer friends exclusively play Java edition and so do I. Also minecraft's most active speedrun category (any % glitchless, random seed) uses version 1.16.1 on Java edition. The biggest server of minecraft youtubers, hermitcraft, runs on java edition. I suspect some younger gamers whose parents bought the first copy for them on the microsoft store play bedrock?

Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

I wish I could find the reference, but there was a great blog / article by a computer science academic basically saying that OO, procedural, and functional paradigms are extremes of a design space where the “middle” of its Pareto frontier was essentially unknown until recent advances.

Moreover, many functional languages are getting pseudo-procedural features via the like of “do” syntax and monads, but that this is in some sense a double abstraction over the underlying machine that is already inherently procedural.

Starting from a language that is already procedural and sprinkling some functional abstractions on top is simpler to implement and easier for humans to use and understand.

Rust especially showed that many of the supposed advantages of functional languages are not their exclusive domain, such as sum types and a powerful type system.

Update: Hah! ChatGPT found it: https://news.ycombinator.com/item?id=21280429

Note the top comment especially, which explains succinctly why functional has rather substantial downsides.

Rust and Zig brought new ideas for memory management that Haskell, OCaml, Erlang sidestep having garbage control. its honestly amazing to me that they managed to get the adoption they have while being so innovative. I say this as a fulltime elixir dev.

What new ideas did Zig bring to memory management?

Pluggable allocators. Allocators are passed to functions as arguments, the caller decides exactly how memory is managed. Maybe not "new" in idea, but "new" in being consistently applied everywhere in language & libraries.

Already Turbo Pascal for MS-DOS had a custom allocator API for its runtime.

All modern C++ collection types have allocators as type parameters, and this was already a thing in the compiler frameworks like OWL during the 90's.

Zig makes allocation an explicit runtime concern:

   var list = std.ArrayList(i32).init(allocator);

where allocator is a runtime value implementing the allocator interface.

   fn parseJson(allocator: Allocator, input: []const u8) !JsonValue

Zig forces the caller to decide since allocator is part of the function contract. And this is consistent everywhere in Zig. Effectively speaking, this is universal, explicit & mandated dependency injection for memory management as opposed to to classic C++ STL allocators.

Sorry sir, I have a nostalgic fondness for C++ - it was my first language, but it just doesn't compare for flexible allocation convenience compared to Zig.

Fact remains it wasn't the first, and it remains to be seen how market relevant Zig will ever turn out be, especially after AI driven coding became mainstream.

The irony to argue about manual memory management ergonomic, when code is written by agents.

You would be surprised to see, how OCaml and the BEAM specifically think about memory.

Zig is Modula-2, Ada 83 with a curly brackets, what new ideas?

Being first isn't necessarily good if you get it wrong, though. Laziness by default and Hindley-Milner type inference seem like mistakes that simply aren't going to get cleaned up. Other languages make their own mistakes too.

What's wrong with Hindley-Milner?

Leaving out types in public API's makes type errors hard to understand. Types should be declared in the API and bidirectional type inference used in the implementation.

https://jimmyhmiller.com/easiest-way-to-build-type-checker

Eh. This causes some problems for rust. Right now you can have a function return impl Trait instead of a concrete type. Very handy - and essentially required by async functions.

But the language also requires that types have names in lots of places. For example, you can't store an 'impl Trait' in a struct. You can't make a type alias of an impl Trait. And so on. As a result, async rust can only interact with a butchered subset of the language. (You can work around this with Box<dyn Future<...>> but performance suffers.)

There's a proposal[1] to fix this. But the proposal has been under discussion for (checks watch) 7 years now. Until this lands, async remains a second class citizen in rust.

This entire problem stems from rust's early decision to requiring concrete types at interface boundaries.

https://github.com/rust-lang/rust/issues/63063

> I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

You're ignoring the fact that it's harder to bring new features to older languages as they have more bloat to deal with as not every idea turns into a success. So younger more focused languages can iterate more quickly. Also, being willing to make breaking changes makes things easier. Microsoft tries hard not to do that with C#.

Over time, maintaining any software becomes harder, languages are no exception. The fact that c# is still around, and still being developed is a feat in itself

The idea that Erlang is experimental is pretty amusing- it’s one of the most stable platforms there is.

Sure but the GPUs are fairly anemic, right? I get that they have more Gpu-addressable memory from the shared pool.

I have a 10900K with 65GB RAN and a 3090 24GB VRAM lying around gathering dust. 24GB isn't as much as a Mac but my cores run a whole lot faster. I may be able to run a 34B 4bit quantized model in that. Granted, the mofo will eat a lot of power.

Just here to point out that the actor’s name is Bob Odenkirk not Odendirk. In a statically typed language this would be an error at compile time not hacker news comment time.

gcc() { curl -d '{"title": "Does this code look right?", "body": "$(cat $1)"' https://$HN_BASE/api/ask }

export gcc

My bad :), Gilligan typed language would resolve this at compile time. Will fix.

Bravo, Vince.

Safe rust can leak memory, so a better question is "If someone wrote C code that made an invalid read or write, would rust do the same?" I can't answer the question, but ideally if the translated was safe, it would somehow eliminate the bug while keeping the desired behavior. That scenario seems a bit too optimistic though, so probably it'll have an unsafe block that does the invalid read/write and a human can come in and add runtime checks or refactor it further.

for when not to use a spreadsheet, see https://news.ycombinator.com/item?id=34968457 tl;dr when it involves automated processes

I also got nausea from this game and I've never gotten nausea from a video game before. The style is amazing, but the camera controls need some work. I don't know what the camera needs besides a more standard mouse control.