markhahn

22 ms·

331.
by markhahn 3y ago
Why does anyone actually give a damn about desktop trivia? I can sort of understand getting uptight if you're a huge fan of tiling, for instance.
332.
by markhahn 3y ago
"barely make a living" is what a normal business aims for.
333.
by markhahn 3y ago
surely you mean that the FS should calculate the hash on file creation/update, not take some random value from the user. but I agree that a FS that maintains file-content hash should allow clients to query it.
334.
by markhahn 3y ago
This logic depends on law-breakers being fully rational agents. Yes, there are some, at least some of the time, but very few.
335.
by markhahn 3y ago
since there's "always another circumvention" we shouldn't even bother right? the "there are always bugs" refrain is horribly corrosive - it doesn't absolve the victim in any sense.
336.
by markhahn 3y ago
Obviously, we want owners to have full access to their car's CANBUS. So the question is: how should the OBD-2 plug (or wiring) be protected?
337.
by markhahn 3y ago
always first blame the flawed security. sure, also blame attackers. never blame the attacker's tools. this is a place where "victim-blaming" is exactly the right thing to do. we can be supportive, even empathetic, of victim
338.
by markhahn 3y ago
Data autonomy. How do we get across to people that there's real value in owning your data - controlling it, hosting it, not just being someone else's product. Why should we not take the broadest possible view? You own your likes
339.
by markhahn 3y ago
what, no blame for the stupid mobile providers who let themselves get social-engineered?
340.
by markhahn 3y ago
It's interesting that this paper, and even the one it references to blame the kernel - these groups don't seem to be interested in fixing kernel problems. Maybe it's just that there are more people doing research on the appl
341.
by markhahn 3y ago
nice: friendly but also succinct. how many people are using systems like cmake (or worse) who would be fine with just make (used right)?
342.
by markhahn 3y ago
too circumlocutory, didn't read.
343.
by markhahn 3y ago
I'm sorry for his endangered hearing. Servers belong in the DC where their noise isn't such a problem...
344.
by markhahn 3y ago
ssh is fairly often used non-interactively. so if you want to execute uptime on a remote machine, the session will only be open for a few ms, and those extra RTT are a problem. (Yes, I know about openssh controlmaster...)
345.
by markhahn 3y ago
right, so if you already have a huge security problem, there are a narrow set of cases where this might allow fairly minor weakening of your ssh sessions (if you don't perform the straightforward mitigation).
346.
by markhahn 3y ago
if you think you're exposed to MITM, then disabling the chacha cipher probably makes sense. there are others that are widely implemented (depends on your clients, really).
347.
by markhahn 3y ago
not a lot. first need MITM, and that's not trivial. next need to be running to asyncssh (which has a straight-up bug in its state machine). next need to be running specific ciphers which use the ssh packet sequence number in their IV
348.
by markhahn 3y ago
we need to blame the failing party (Comcast here), we need to make customer data outrageously radioactive, so companies like Comcast try hard to avoid storing it...
349.
by markhahn 3y ago
interesting, and indeed I'd never heard of them. of course, there's also the IMSAI. I personally lusted after the Sol (real wood sides!) Intellec seems to have been missing from the hobbyist headspace, though, which was critical
350.
by markhahn 3y ago
that's the tape market I mentioned. agreed, tape doesn't fit the personal market, but it totally dominates anywhere that has scale. the question is: what counts as reliable? if PLC is good for 50 erasures, are you really comfort
351.
by markhahn 3y ago
Look at the numbers. Power/heat matters for datacenters, but not for people. Yes, you can built a kw desktop, but you know you're doing something weird. For most people, their computer's peak dissipation has been falling fo
352.
by markhahn 3y ago
heat density is heat density. this technique isn't the same as stacking two logic dies (which would have a heat problem). backside power is actually a pretty important power improvement - both delivery and cooling.
353.
by markhahn 3y ago
the case for inductive stacked chips is pretty compelling, if those slides are right! I wonder if you can also couple adjacent chips that way, since 2.5D is, if anything, more important than stacking...
354.
by markhahn 3y ago
TLC is a decent spot, which is why it's still being produced. QLC is less so, since its endurance is only ~300 cycles. there's plenty of tension in the storage industry about this, with vendors saying "don't worry be ha
355.
by markhahn 3y ago
cache latency is definitely part of what limits core clock. you're not going to have a good time if your L1 latency is, say 10 clocks. not to mention the fact that register files are not much different than SRAM (therefore cache-like
356.
by markhahn 3y ago
cost is area, because defects. TOF latency isn't that much of a big deal, though driving a signal for distance consumes a lot of power, and power has been the primary design-limiter for at least a decade.
357.
by markhahn 3y ago
really compact DRAM? have you seen DRAM? the aspect ratio is already huge, though afaik no one stacks the pass transistor. high-end systems already have stacked DRAM chiplets, though admittedly this hasn't made much of an appearance
358.
by markhahn 3y ago
arguably, the current race is down to TSMC making the right decision on hi-NA EUV (ie, to run with low-NA). it's not as if Intel couldn't have acquired EUV, they just chose not to.
359.
by markhahn 3y ago
well, sorta, since caches are just sram+tag logic. you can parallelize tables, so that each remains fast, but it costs you power/heat. the decoder inherent to sram is what introduces the size-speed tradeoff.
360.
by markhahn 3y ago
stacking is a heat problem, and heat has been the PRIMARY system limit for over a decade. 2.5d is just too easy and effective - we're going to have lots more chiplets, and only the cool ones will get stacked.

More ›