mmt

58 ms·

451.
by mmt 8y ago
> Well, take a simpler case: A program that takes a lock and then reads a file specified by the user on the command line. I'm having trouble seeing the use case under that Unix Philosophy constraint. I admit I might not be imaginati
452.
by mmt 8y ago
8-10 years ago is a very long time, especially for what was still a relatively new, low-volume product in the consumer market. > I assume they've improved in that regard, or are spinning platters still a safer proposition over the l
453.
by mmt 8y ago
I can't claim to speak for the designers, but my intuition (having had my first Unix exposure in the early/mid-80s) is that their assumptions were along the lines that it would be used consistent with the part of the Unix philosop
454.
by mmt 8y ago
> the advisory locks were owned by individual threads. Eventually (probably after the change to NPTL and improved kernel support for threads) Isn't that because, in the time prior to that "improved kernel support", threads
455.
by mmt 8y ago
> processes give parallelism as well and predate the introduction of threading interfaces Right, but the reverse isn't true, which is what I was getting at. That is, availability of hardware parallelism was a prerequisite for anyone
456.
by mmt 8y ago
As the sibling comment implies, I don't mean SMP anywhere in computing, I mean in the Unix world, which didn't even exist in the early 1960s. I'll grant that my early Unix knowledge is far from comprehensive, primarily skewed
457.
by mmt 8y ago
My (admittedly quick) reading of this is that the issues stem, primarily, if not exclusively, from using multiple file descriptors for the same file, necessitated by using/supporting threading for concurrency. If that's the case,
458.
by mmt 8y ago
At the risk of sounding too glib or reductio ad absurdum : The best code is impossible to spot, because it's not even there. Put another way, a truism I've often heard from the most senior programmers (especially in the context o
459.
by mmt 8y ago
> If we had that information, then you could answer some of the questions asked surrounding the deprecation schedules of HW in a DC the size of Amazon. But we still don't, so we still can't infer anything at all from the announ
460.
by mmt 8y ago
> P.S. The article is about Intel's ME flaws and patches so probably our whole discussion branched off in the wrong direction :). Maybe that's why I was confused? I thought we were talking about commodity, x86 servers all along
461.
Intermitent audio after Roku 8.1 upgrade(forums.roku.com)
1 points by mmt 8y ago|0 comments
462.
Audio Skipping on Roku Ultra (2016) After 8.1.0 Update(reddit.com)
1 points by mmt 8y ago|0 comments
463.
by mmt 8y ago
I'm just wondering if "those systems" include any present-day x86 servers. If not, then it's safe to say they're a red herring, since this whole discussion is based on an article about, specifically, Intel CPUs.
464.
by mmt 8y ago
It's also never quite as simple as looking at each generation as a discrete unit of upgradability. Not only can the price:performance spread vary between generations, but this can change over time, particularly because the model availa
465.
by mmt 8y ago
I realized my (own) sibling comment sounded like a bunch of rhetorical questions, since they were asked from the standpoint of my skepticism/suspicion based on what I read. However, they actually are questions, and I'd appreciat
466.
by mmt 8y ago
Indeed, I remember when PhoneNet made ad-hoc AppleTalk networks a bit easier (although, by then, the LocalTalk hardware, genuine and clone, was common enough, too, except sometimes long enough cables could still be a rarity).
467.
by mmt 8y ago
I don't see much, if any, novelty here, especially if one substitutes the synonym "Marketing" for "Evangelizing". I vaguely recall it being something of a trope in the software industry (perhaps not even limited to
468.
by mmt 8y ago
> I believe individual investors will bridge the information asymmetry, since regulation of anonymous fungible crypto is bound to fail I'm not sure I follow. I'm willing to assume the latter as being true, but how does that fai
469.
by mmt 8y ago
> An IT illustration: there are still places running RHEL6 in production and not seeing an effort to migrate from it worth the while. I recently interviewed at a startup (though a reasonably far-along/mature, if not spectacularly su
470.
by mmt 8y ago
> And TBH replacing servers after 2 years because you're worried about uptime feels like a horrible overreaction and self harming at the same time. I agree. Such a tactic, in the face of modern high-availability systems design (incl
471.
by mmt 8y ago
I actually have no idea if you're right or wrong. However, one of my primary concerns regarding any "crowd-source" or direct-to-retail investment in startups is the information assymetry. It's tough, if not impossible (a
472.
by mmt 8y ago
I was going to comment about this but wasn't quite sure what to make of it. However, I would not characterize what the article encourages as lying, but, rather, bluster is the word I'd choose. More importantly, my impression of th
473.
by mmt 8y ago
The problem with that glib-sounding notion is that, besides being, potentially, a chicken-and-egg issue, is that the amount of available, suitable land is much more limited than the vastness of, for example, the USA, would suggest. The fi
474.
by mmt 8y ago
> Yes, of course, with cloud infrastructure or just virtualization and spare hardware, service contracts have much less value. My assertion is that service contracts for hardware have zero value for commodity hardware installations (be
475.
by mmt 8y ago
I wasn't suggesting that research can no longer exist, just that the OC's whole point was that this field is no longer about just research and attempting to open up the discussion to a broader interest group, of software enginee
476.
by mmt 8y ago
> that is a reason it has been avoided by VCs? Not many 'purely' software options? This does strike me as reason enough, yes, not that it's necessarily rational. Although there are certainly VC dollars available for non-so
477.
by mmt 8y ago
> the scale of money involved [1] And yet in that very example, that scale of money is involved for a battery solution. Notably lacking is how software, or computer technology of any kind, contributed to that dollar amount. I don'
478.
by mmt 8y ago
> pouring millions into 'smart grid' R&D Unfortunately, that essentially contradict's the GP's "isn't a research problem anymore" assertion. Similarly, millions, even tens of millions, isn't an
479.
by mmt 8y ago
Indeed. Energy in chemical form is astonishingly cheap to transmit (and store), but, as electricity, it's completely different. The storage problem is part of the point of the article, of course. I always thought this was one of the ad
480.
by mmt 8y ago
I would only do it if either I actually controlled the software that did the turning off or there were a third-party that could be trusted to monitor and provided an escrow account with a huge financial penalty payable to me if the utility

More ›