412 karma · joined May 30, 2020
He was able to identify a large group of CPUs used in W680 chipset motherboards (i.e. using stock Intel power curves, never seeing a lick of overclocking/overvolting) which exhibited issues.
It would seem enthusiast ricing is, at best, an aggravating factor to some other underlying cause.
I find using a ssh-agent to load password protected SSH keys works best.
With Xpra you have a headless X session on the remote machine and you "detach" and "attach" to it from the client. So whatever X applications you leave running will be right where you left them.
This is in fact pretty unactionable unless you are planning on boondocking during your career and retirement - at which point - why bother with post secondary education and a white collar job in the first place, just boondock from the getgo.
I don't believe that I said it was not. Although, you should look at France as a special case.
> You can of course turn the output of a nuclear plant up and down, reasonably quickly.
Well, yes and no. Most contemporary reactor designs do have the physical capability to fluctuate between about 30%-100% power. But the ability to model such a core (accurately) has been a relatively recent thing, which has knock on effects for developing a core loading plan, doing a safety analysis, and performing monitoring/prediction. This was because most of these reactors were specifically built to satisfy base load requirements for their communities, there was no demand to develop the methodology initially. The whole economics reason came about much later when people started talking about actually developing said methodology. Its kind of a big deal because your AO bands are part of your licensing basis.
This is a historic limitation. We have the technology to perform load follow with the legacy fleet. Most utilities just designed their fleets around the assumption that nuclear would be base load and therefore are less incentivized to operate their nuclear reactors this way.
And I'll also add that at no point are you ever going to need to flash the ECU with updated firmware.
So while a cute example, it isn't really a practical example. Typically when people complain about "code rusting", it is in the context of a codebase that needs to adapt to the world around it; whether that is communicating with other systems or even just accepting new features within its own little fief.
I think I am uniquely qualified to speak authoritatively on this subject as I regularly work in code bases dating back to the mid 1950s (nearly 70 years old if you are counting).
Code left alone absolutely does rust. Everything around the code changes, you can wax philosophically about how "technically the code didn't rust the world did", but at the end of the day that old code aged into a position where it no longer functions optimally or even correctly.
Just to tease with an example, the original machine some of this code was written for only had a few kilobytes of memory, half of which was taken up by the OS and compiler. In order to fit the problem you are working on into memory, they effectively wrote a custom swap allocator that looked and felt like you were using in-memory arrays but were actually using tape storage. Fast forward to today where we have a single compute node with 128 physical CPU cores and a terabyte of memory, the code still diligently uses disk storage to minimize RAM consumption but runs like dog shit on a single thread anyways. Not to mention all the integers used to store pointers have had to be widened over the years as you went from 48 bit words to 32 bit words to 64 bit words.
If there was no trust, they wouldn't be asking you to do the work in the first place.
Ridged top-down organizations wither away and die because they lack the agility and insight to respond to unexpected conditions. Leadership can set the high level goals of a mission, whether they like it or not, they need to also give the autonomy and authority to the field commanders to achieve those goals however they see fit.
If you are concerned your field commanders are going to go off and not stay focused on the goals then you've promoted too early.
The time for sitting around a table and talking openly at a higher organizational level is when deciding what goals to set, not in the heat of battle, unless it is to call a retreat.
It is only time to pack up when leadership is so full of itself that it cannot understand this.
Of course, you could argue that having a funding structure that necessitates padding in the first place is the early signs of the wheels coming off - which I would agree with.
In practice, Product often controls the budget. So even if Product doesn't have the explicit power to veto a refactor, they have a lot of implicit power to deny this by only allocating enough to get a feature done.
Now if you care, you just pad estimates and don't mention that there is a 20% tax or whatever for refactoring.
That doesn't work in all cases, especially if the code base is particularly tangled. But you can get a lot of small things done this way.
On the same "holder", no, just due to how the wire is fastened to the poll. On the same poll, maybe, depends on how much poll real estate is available. Usually though there is not extra space available. High voltage conductors use the air gap as part of its insulation so to prevent arcing the conductors need to be spaced out so far apart.
What if the trojan is in microcode? No amount of bootstrap in freestanding can protect you here.
Well...no actually.
This may be the case for _some_ software. I happen to work on (software) products where public safety is a concern.
You call up your local nuclear reactor spare parts vendor and place an order. Then they figure out how to either source the part or manufacture it or substitute it.
No, really. Most places that sell nuclear fuel have a spare parts business too.
One of the bullets on the box is that the AP1000 uses a fairly standardized design, unlike many prior designs which were mostly a patchwork of one-off designs. The AP1000 still being "in production" means parts are available.
FYI, this is a pretty typical industry term. Even to the point where "burn up" is a unit of measure tracked at operation and within model predictions.
I have long since moved away from optical media, really for anything, but especially archival. Long term storage to me looks like an array of magnetic disks held together with ZFS.
Do you just not review the configuration of your networking equipment?
It is a convenient way to maximize hardware in SOHO deployments.
I cannot disagree with you more.
Most places, especially ones that don't specialize in coffee, do not properly clean their equipment and prep the brew.
If I was just a junkie, I would use cream and sugar at home too.
If you think about it, "base load" has nothing to do with the power source. Given some period of time, say a day, you are always going to have a certain minimum demand for power generation in a geographic location. Congratulations, you have identified base load.
As the grid becomes more distributed and therefore less centralized, you are going to see base load hitting lower peaks because individual power generation stations will have less aggregate demand. But until society reaches a point where at least part of the day there is zero demand on the grid (fat chance) you will always have base load in some shape or form.