Hacker Newsnew | past | comments | ask | show | jobs | submit | Delk's commentslogin

You could do all of those things on an OS with proper security separation as long as you have full root access.

There's no megacorp stopping you from reading and writing kernel memory. Unless, of course, the computer refuses to run software not signed by the megacorp or some software refuses to run without a digitally signed chain all the way down to the firmware like some game anticheats do.

But that's not really because of things like permission boundaries for processes. You can have those and still be in full control of those boundaries. It may be more convoluted than in a barebones system like DOS, of course.


PatchGuard would like to have a word with you.

> I’m still at where when I connect external hard drive or SSD via USB, use it and then eject it, I shut down the MacBook Pro completely before I unplug the cable. Just in case.

That sounds... a bit paranoid? At least on Linux (Gnome), if I click to "safely remove drive" it actually powers off the drive and stops external mechanical drives from spinning. No useful syncing is going to happen anyway once a hard drive no longer spins. A modern OS should definitely be reliable enough that it can be trusted to properly unmount a drive.

> For the laptops that I actually carry around and plug and unplug things to etc, normal amount of time between reboots for me is somewhere between every 1 and 3 days. Cold boot is plenty fast anyway, so shutting it down after a day of work or when ejecting an external HDD or SSD doesn’t really cost me any noticeable amount of time.

I personally don't reboot my laptop that often, but it's not because of a boot taking too much time. It's because I like to keep state: open applications, open files, terminal emulator sessions, windows on particular virtual desktops, etc.


> A modern OS should definitely be reliable enough that it can be trusted to properly unmount a drive.

The problem isn't just in the OS side of the stack. Disk firmwares - especially SSDs - love to lie to the layers above [1].

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


A lot of that probably came down to the motherboard chipset. IIRC Intel made their own chipsets for the Pentium III and they were good and reliable. Athlons were coupled with chipsets from VIA and whatnot.

Some of those chipsets were fine and others were less reliable or compatible. The quality of the drivers for each chipset may also have mattered.


I almost never get Firefox crashes on Linux, and I don't remember seeing significant slowdowns with text boxes either, at least not simple ones.

How long are the inputs that you get problems with?


If running low on memory seems to matter less now than it did a couple of decades ago, I'd rather say that's because fast SSDs make swapping a lot faster. Even though virtual memory and swapping were available even on PCs since Windows 3.x or so, running out of memory could still make multitasking slow as molasses due to thrashing and the lack of memory for disk cache. The performance hit from swapping can be a lot less noticeable now.

Of course compression being now computationally cheap also helps.


What do you do to address health concerns before they become ER-level?


Medicaid or ACA subsidized insurance


> Remember, a hash is a "one way function". It isn't invertible (that would defeat the purpose!). It is a surjective function. Meaning that reversing the function results in a non-unique output.

This is a bit of a nitpick and not even relevant to the topic, but that's not the reason cryptographic hashes are (assumed to be) one-way functions. You could in principle have a function f: X -> Y that's not invertible but for which the set of every x that give a particular y could be tractably computed given y. In that case f would not be a one-way function in the computational sense.

Cryptographic hashes are practically treated as one-way functions because the inverse computation would take an intractable amount of time.


Yeah that's a good addition. I think often the words we use can really make things more confusing. Like I hate when people say invertible but in reference to a function that isn't bijective. Why not say reversible? (No complaints with the convention of image/preimage)

Which it's very similar to the problem created by saying "one way". It just isn't one way. Going the other direction is perfectly possible but incredibly hard to find the origin. The visual metaphor I like to use for people is it's like you walk out of a room and into a hallway of doors that are all identical looking. Ignoring the fact that you could just physically turn around, it'd be very hard to figure out which one you actually came from.

But maybe what I like least is that we end up having so many terms for the same general concept. It's one thing when they're discovered independently but I'm pretty confident the computer scientists that pioneered hashes were quite familiar with the mathematics and nomenclature.

  > inverse computation would take an intractable amount of time.
On a real side note I really like this explanation of P vs NP as it explicitly talks about reversibility. https://m.youtube.com/watch?v=6OPsH8PK7xM


> biwepe(?)

Probably beweep; lament, weep over.

> pinunge(?)

This is explained later on the page. "Where a modern writer would say he underwent torture, a 1200-era writer must say that he suffered pinunge instead."

I also couldn't understand this one although the word "pining" did come to mind, apparently not totally off, as that has apparently come from the same ancestor. Didn't help me figure out the intended meaning, though.

> No scar(?) is never hit(?) forgotten, not uuhiles(?) is libbe(?).

I guessed this meant something along the lines of "[?] shall I never [?] forget, not while I live". I didn't figure out that "uu" is actually "w" until that was explained, so it escaped me that "uuhiles" is "while[s]", though.


In current Limburgs, pinige: to torture. Mien herses pinige: Wrecking one's brains.


surely "paining" is the easiest way to comprehend it


Yup, definitely easiest. (That's how I first got it too.) Dunno if it's ethymologically correct, though; that depends on what the roots of "pain" are.

Since it's explained further down the page that it comes from an earlier loan from Latin "peona", "punishment", I suppose there is kind of a cognate in English itself from the later loan of the same word that has lead to "penalizing".


I think Transport Fever is of a slightly but significantly different genre.

Railroad Tycoon is a strategy game with competition whereas Transport Fever is pretty much a building and optimization sandbox. Even Transport Tycoon falls more in the latter category, IMO, despite superficially having competition even in single player. (I haven't played OpenTTD in a long time so I don't know if the AIs are nowadays competent enough to make the competition interesting.)

In RRT, with cut-throat competition enabled your company can even be opportunistically bought by the competition if you aren't careful. You can also be driven out of cities by rate wars. Some of the other strategy aspects feel perhaps a bit artificial -- you can't cross the other companies' track, for example, so you can effectively cordon off areas from competition. Nevertheless, those competitive strategy aspects add a significant edge to the game.

I've also played a lot of Transport Fever. The competitive aspect, even if against the old and cheating AI, is probably one of the reasons I still end up returning to the old Railroad Tycoon now and then, though.

Some of the technical limitations of the original are somewhat frustrating, though, so I find the reverse engineering effort really interesting.


It actually says "hacking on one of our programs", which makes it even more obvious that it's using the word closer to the positive traditional hacker culture sense.

I'm sure that still looks unprofessional to some people, just like any jargon that isn't corporatese does.


I could have been giving this an uncharitable reading.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: