> Are you saying that this isn't political? It's literally about politics.
Sure it's about politics, but it's also about tech. The intersection of politics and tech is a fascinating area, of great interest to many folks on HN, and probably within HN's charter.
I think that merely touching on politics should not be grounds for flagging a submission, even when the specifics are highly controversial (as in this case).
> Capitalism allows individuals to take decisions in a free market.
Capitalism provides a set of incentives that shape how people make decisions. Anyone can be selfish, but selfishness in capitalist society has a particular shape. To ignore the external incentives when looking at human behavior is horribly naive and shortsighted, but is frequently done by capitalism-apologists who seek to disregard any criticism of their favorite incentive system.
We could invade other countries and take their actors. We could reinstate the actor's draft or do mandatory 1-2 years actor's service like some other countries do
The domain name reminds me of the venerable DOS "debug.com" command, which managed to combine an interactive and scriptable debugger, assembler, and disassembler into a program weighing a few kilobytes. I spent many long hours in my youth using it to reverse engineering copy protection on games. I really wish we had a similar tool for the modern era.
Sure I remember, but since I purchased Spinrite doing lowlevel was needed just once while changing ST-506 controller to a different type or for a new disk, former was quite much rarer needed.
Then even after std lowlevel it was worth using Spinrite to check if interleave value was proper. And if it wasn't it was worth letting it first before anything else. Same when changing a faster CPU as it could speed up IO so much that no interleave would not needed any more and get faster IO.
Spinrite was such a great tool and time saver fixing or making preventive periodic maintenance to customers disks, even though it chugged hours even 30M disks. And just because not to take absolutely any risk it was necessary to make full backup first, which that took quote long also. LapLink was a great tool for that, before LAN became more common.
But it's when you consider taking first full drive backup times. It still takes 'forever' when you'd rather like to get on with fixing single disk issues. Or like when you wait RAID rebuilds too.
We did plan our maintenance tasks so, that there was something else useful we could do while obligatory backup and Spinrite was running. Upgraded another devices EPROM's, PC BIOS or dot matrix printer EPROM, cleaned printer heads, chaff and dust from chassis, changed colour ribbon to it. Ran updates to software we had sold etc. And went lunch with the customer:)
It turned into 5 days. After realising I'd forgotten to change the block size to 4096 and it was horribly slow, I yanked the drive out, tried with my utility to set it to 4096 bytes and failed, found another utility that did the job, put the drive back in, wait 3 days for it to rebuild the array without the new disk, and then another two days to add the disk back in. Sigh.
Still, with 4k block sizes, it goes like shit off a shovel.
WinDbg is just a debugger: it does not assemble or disassemble. It can't patch running programs in memory. Moreover, I don't consider Windows to be part of the modern era, as I haven't used a Windows machine for 20 years.
A more apt analogy: I don't consider North Sentinel Island to be part of the modern world, since there is no relevant innovation going on there, it has no influence on the rest of the world, and there is nothing to be learned there.
You miss debug.com, wish there was an equivalent for the modern era, find out that windbg does almost all these things today, and say there's nothing of value there.
I say this as something who does all the things you described debug.com as doing, in this modern era.
Maybe so, but that's not what you claimed. You claimed that WinDbg "does not assemble or disassemble", when of course it does. Try to be more accurate with your claims if you want serious people to take you seriously.
Actually, I didn't even get to this part of your message, windbg absolutely can patch currently running programs. It does all the things you think it can't do.
Okay, but is it not what you wished for, "a similar tool for the modern era"?
edit: I see I simul-posted with u/modeless, but I can't remove it now that there's a (duplicate) reply. Maybe mods can remove or at least collapse mine (their ID is one lower so they were first)
WinDbg is just a debugger: it does not assemble or disassemble. It can't patch running programs in memory. Moreover, I don't consider Windows to be part of the modern era, as I haven't used a Windows machine for 20 years.
If OP wanted to know whether WinDbg and debug.com can be considered feature-similar, they could have read my first comment [1], where I specifically said that debug.com is a "debugger, *assembler*, and *disassembler*". Of those three features, WinDbg provides one.
> Sounds like you aren't familiar with Nvidia's dedication to low-power ARM SOCs. Ever heard of the Nintendo Switch before? The Tegra inside that is a 15w TDP gaming SOC. And it supports CUDA (somehow).
I think that GP comment is not intending to throw shade at ARM SOCs (many of which are quite nice, including those from Apple an Qualcomm), but specifically the Microsoft products built on them.
I'm mostly surprised by the insinuation of bad performance or battery life. That's what will be ostensibly solved by putting an Nvidia SOC where a Ryzen or Intel one used to be.
Has this chip actually been used in any real product yet? Nvidia has, er, a bit of a historical problem with overpromising and underdelivering with their mobile chips (in particular see the Tegra 2 and Denver); I would be cautious until there are real benchmarks. It's hard to describe any previous Nvidia general-purpose mobile chip as anything other than a failure.
I agree that that's the point he's making, but I don't see how that would work practically. His attitude is that malloc(1<<63) should immediately crash the system, every time? How is that better?
No, if a process allocates an infeasible amount, malloc fails and the process needs to deal with the failure (which is what already happens, "malloc doesn't fail on Linux" is only really true for smaller-than-page-size allocations). The point being made is that the system should account conservatively for all memory that can be used, not just the optimistic underestimate that overcommit enables (i.e. the plane should always carry enough fuel for contingencies, and landing with extra fuel is a good outcome).
You never need to crash the system if you remove overcommit. You just crash the one process. Practically speaking, you don't even need to crash here; you just return null (which malloc is always free to do) and let the consequences speak for themselves.
Sure it's about politics, but it's also about tech. The intersection of politics and tech is a fascinating area, of great interest to many folks on HN, and probably within HN's charter.
I think that merely touching on politics should not be grounds for flagging a submission, even when the specifics are highly controversial (as in this case).
reply