Posts by Crypto Monad 330 posts • joined 14 Dec 2017
> We're getting a 10KW (nominal) rooftop PV install later this year (in Surrey UK), I'd expect 25 years lifespan from that - and as I understand the technology "lifespan" typically means only degradation of output, not that generation ceases completely.
Correct, although you should expect to have to replace the inverter, and batteries if you have them, some time between 10-15 years.
"few in the industry realized just how radical Optane was. And so it bombed"
No. The reality is: nobody wanted to buy it, and hence it bombed.
IMO, the fundamental premise of the article is mistaken. Optane was never suitable for primary storage, for the simple reason that even DRAM is already a massive system bottleneck. Whilst CPUs have increased in speed by 3-4 orders of magnitude over the last few decades, DRAM has increased by maybe 1 order of magnitude. As a result, any access to DRAM can result in hundreds of cycles of CPU stall. In current systems there need to be three levels of cache between the CPU and the DRAM for it to function tolerably at all.
Replacing your DRAM with Optane, making it another order of magnitude slower again, would make this far worse.
The only way it *might* have worked is to use Optane as further tier of caching between CPU and DRAM. But that requires reworking your applications and operating systems, copying data back and forth between Optane and DRAM as it gets hotter or colder - for at best marginal benefits.
That copying is pretty much like swapping. Optane would have been a good location for your swap file. But if you're having to swap out of DRAM, your performance is already suffering badly, and Optane would just make it suffer slightly less. Similarly, Optane could have been used for the page buffer to cache data fetched from SSD - but if your data is a small percentage hot and the rest cold, then the hot is already cached in DRAM anyway.
In short, it was an expensive solution looking for a problem. If it could have been made as cheap as SSD, then it would have won because of its higher speed and endurance. If it could have been made as fast as DRAM, then it would have won through lower cost-per-bit (and maybe some use could have been found for the persistence too). Neither of these was true. It was just another type of secondary storage but considerably more expensive than SSD, which the market considers "good enough" in that role.
My preferred solution to this is to introduce some sort of "Universal Time" (not the same as UTC) which doesn't have leap seconds or smearing, so would wander from sidereal time over time, but would therefore also give a reliable measure of the difference between two time points.
You mean like one of these?
https://en.wikipedia.org/wiki/International_Atomic_Time
https://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping
https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS
Meta are free to switch from using UTC to TAI or GPS, if they so choose. They don't have to persuade anyone else to do this.
The impact will be on libraries which convert utime to human-readable date/time: those will need changing to account for leap seconds. I'm sure Meta can afford the resources to maintain their own libc fork and their own TZ database.
Their applications will also need to be careful not to hard-code things like
day = utime / 86400
time = utime % 86400
which are quite tempting short-cuts for programmers.
Thank you for that, it led to some interesting reads:
https://en.wikipedia.org/wiki/ValuJet_Airlines_Flight_592
https://www.theatlantic.com/magazine/archive/1998/03/the-lessons-of-valujet-592/306534/
Wikipedia says simplistically that the canisters were expired but labelled "empty". The second goes into much more detail:
According to ValuJet work card No. 0069, which was supplied to investigators, the second step of the seven-step removal process was If generator has not been expended, install shipping cap on firing pin.
This required a gang of hard-pressed mechanics to draw a verbal distinction between canisters that were "expired," meaning most of the ones they were removing, and canisters that were not "expended," meaning many of the same ones, loaded and ready to fire, on which they were expected to put nonexistent caps. Also involved were canisters that were expired and expended, and others that were not expired but were expended. And then, of course, there was the set of new replacement canisters, which were both unexpended and unexpired.
> I suspect if all books were mandated to be green of red "leather" bound and use the same typeface for gold leaf printed authors name and title, you'd rarely spot an "interesting-looking book".
See the Two Ronnies:
https://www.youtube.com/watch?v=8dZznfGPYRY
> Down votes without enlightening comments demonstrate pique power?
Very clever. Have a comment anyway.
I've just had domestic solar installed. There are two "strings", with 6 and 8 panels in series. The voltages are around 200V and 270V per string, and a peak current of around 12A, so the ohmic losses are no greater than regular domestic wiring. There are 'optimisers' fitted to each panel to ensure that if one panel reduces capacity, it does not affect the others.
I can tell you that the copper wiring between the panels and the inverter did not make up a significant part of the system cost.
No doubt the inverter and batteries, and even the panels themselves, have some copper inside them. That cost is hidden, but again I think the amounts are small.
Electric motors in EVs though - that's a different matter.
> If ammonia were a good source of fuel, the airlines would be looking into it to replace jet fuel, the railroads would be looking into it to replace diesel, and international shipping would be looking into it to replace bunker fuel.
Exactly what I was going to say. If it's a good fuel, then there's no reason to target it just at data centres. Conversely, if it's a bad fuel, then I don't see why data centres would want it when nobody else does.
Personally, I'd say synthetic methane or methanol are a better goal than ammonia. Of course they release CO2 on combustion, but only what was used in its production.
Please correct your units!
"Five mins under an electric shower will burn 1Kw/h"
No: it's 1kWh (kilowatt-hour, not kilowatts per hour)
"*** 12Kw/h element"
No: it's a 12kW element (kilowatts, not kilowatts per hour nor kilowatt-hours)
kW = power = the rate at which energy is consumed. 12kW is 12,000 joules of energy per second.
kWh = energy = the total energy consumed. 1kWh is 3.6 megajoules of energy (1000 joules per second x 3600 seconds per hour)
For the SFC, the break with GitHub was precipitated by the general availability of GitHub Copilot, an AI coding assistant tool. GitHub's decision to release a for-profit product derived from FOSS code, the SFC said, is "too much to bear."
But how is moving away from GitHub going to help, if you still publish your work as open source on some other platform? Or even just as source tarballs? Microsoft will simply scrape that instead.
The only solution I can see is *more restrictive* FOSS licences. Normally these don't put limits on who can use the software, or what you can use it for. Such conditions are explicitly forbidden in the Open Source Definition.
It seems we'll need new licenses that forbid specific uses - such as embedding in code-generation systems or for training AI models.
Even then, it will be extremely hard to prove that your code was used to train an AI, short of whistleblowers.
No need for anything fancy with microwaves to do that. Present-day anti-tank munitions can drill a hole through half a metre of armour in a few milliseconds
Turning that around, I offer the Wile E. Coyote method of drilling bore holes:
1. Light a stick of dynamite
2. Drop it down a shallow hole
3. Go back to step 1
Then you don't need a 20km microwave gyrotron. You just need a 20km vacuum cleaner hose to suck up the rubble.
"Yet if it happens, and keeps happening, why aren't systems more resilient to this sort of problem?"
Conversely you could also ask: given the ludicrous complexity of these loosely-coupled mega systems we're deploying, why don't these sort of problems happen more often?
"Is it actually universally true that state can be retrieved?"
Yes: turn it off and on again.
This is a widely deployed solution, and sadly often necessary when state gets tied up in knots.
Snaps are not just apps installed under their own directory such as /opt/myapp/v1.2.3/ (which I have no problem with).
Snaps are semi-containers. They run in their own namespaces which restrict them from accessing other applications.
This might be fine for straightforward user applications like a web browser, but in more complex scenarios it breaks down in unexpected ways.
Case in point: lxd is now only supplied as a snap. lxd can use zfs for its storage. However, because the snap is constrained to mounting and unmounting within its own namespace, then when zfs breaks, it becomes extremely difficult to fix (the snap thinks that the zfs dataset is mounted when it isn't, or vice versa). Poking around with nsenter may or may not help; a reboot may be required.
In the end, snap treats all packaged software as an adversary which needs to be sandboxed. Does this make sense for end-user apps? Maybe. For system tools? Not so much.
RFC stands for "Request for Comments" – meaning HTTP/3 awaits final signoff
Not really. Once it's been published as a standards-track RFC ("proposed standard"), in effect it's already signed off. Prior to this it would have been a series of "Internet Drafts"
For comparison: RFC2822, which is the still the primary standard for E-mail from 2001 (and replaced RFC822 from 1982), remains a "proposed standard".
> Honest question - how much of the non domestic internet can’t handle IPv6 for public communications?
Answer: most of it.
- Businesses are the slowest adopters of all. They don't like touching their firewalls, or having more complex rulesets, or adding potential attack vectors.
Dual-stack would be fine as a migration tool - e.g. roll out v6 this month, remove v4 next month. But it's not like that, since you can't migrate to v6 without cutting yourself off from most of the Internet. Instead, dual stack is an expensive "forever" proposition.
- Content providers have a pretty poor showing. In theory they can easily make their content available over both v4 and v6, and those behind the likes of Cloudflare can easily IPv6-enable their content at the click of a button.
But many major providers like the BBC are still dragging their feet. They probably don't have a business case for the work involved. Everyone can see them on IPv4, so why spend time enabling IPv6 and debugging any associated problems? Does all their logging and tracking and monetising work with IPv6? They won't want to risk any problems with that.
- As for domestic Internet: home networks are a mixed bag. Mobile networks in much of the world are the leaders here, since any traffic they can shift onto IPv6 is traffic shifted off their CGN (and the biggest content by volume, i.e. Google/Youtube and Facebook, is already accessible via IPv6). So there is a direct business case for them to do it.
This isn't going to fly.
I was recently bitten by a much smaller example: I was in a hospital in Copenhagen, and the wifi network's public IP address was within 128.0/16 (i.e. it was 128.0.x.x). I was blocked from reaching a certain university site, and had to contact the university's network team to resolve it.
It turns out that 128.0/16 was a historical bogon, and despite ten years of work, it's still not been removed from bogon filters everywhere (it's even hard-coded in some router OSes). For more details see:
https://labs.ripe.net/author/mirjam/an-update-on-de-bogonising-12800016/
which was written in 2013.
So I can tell you now that the proposed new blocks will be utterly worthless. Please stick me behind a CGN, rather than assigning me an address from 0/8 or 127/8 !!
"they expressed a desire to increase the rate at which new features are introduced and encourage their adoption"
I would prefer a language which *minimises* the rate at which new features are introduced. Each feature adds cognitive load, and whilst it may make certain patterns shorter to code, it makes them harder to read.
However, whatever you think of Perl, you can't accuse it of developing too quickly over the last 2 decades.
> Hmm, with a simple shell script for-loop you could even loop through a whole series of ASCII art images and make flipbook-style 'videos'
No need. ASCII art can already replace Netflix: most of Star Wars has already been re-shot in ASCII.
telnet towel.blinkenlights.nl
I'd like to see aliens decode H.264 without a manual. But that's by the by.
The objective here, apparently, is *not* to act as a library of human knowledge in the event of the human race being wiped out. If it were, the main goals would be making a storage medium capable of retaining data over millions of years, and the retrieval manual to go with it. Such a rugged data storage system could just be preloaded with data and launched as-is, with an update sent after it every couple of years.
However, it seems what they're *actually* trying to do is to sell Disaster Recovery as a Service, with a measly 16 terabytes of storage. Here: take this LTO-8 tape.
If all the data centres on the world are destroyed by nukes, having a backup copy of your data on the moon isn't going to help you much. And if there were a data centre on the moon where you could spin up your DR applications, your users would have to cope with a 1.5 second round-trip delay.
Note that with an NFT, all that you actually own is a *URL*. The NFT doesn't even include a hash of the content at that URL.
The server hosting that URL can go away; or the server owner can replace the content at that URL with different content, or even remove it entirely. At that point, all you own is a 404 error message.
The URL, of course, also allows anyone else in the world to look at or download a copy of the content there.
May I propose a solution:
- Script 1 marks listed items for deletion
- Script 2 permanently deletes listed items, but only if they have already been marked for deletion (i.e. selective "empty trash")
If you want permanent deletion, you have to run script 1 followed by script 2. Preferably with 24 hours in between.
> have yet to find a client email package that fully supports Office 365
Thunderbird does the job well enough for me.
In the old days, you needed some middleware (davmail) to speak Exchange's proprietary mail protocols. But Office 365 just does IMAP.
Calendaring? Open your calendar in a web browser, or use the Teams app.
> H2 takes more to create it from water than to burn it, so it's a loser's proposition
No process is 100% efficient - and that includes turning heat into electricity, or storing electricity in batteries.
However, if the electricity you're getting from wind or solar is sufficiently cheap in the first place (or free if it's excess), then it could still be economical even if you lose a substantial fraction.
The main problem I see is that H2 is a terrible store of energy - not just because it leaks, but also because it migrates into the structure of metals and makes them brittle.
If we combine it with CO2 to make CH4 or CH3OH, then we get something much more practical to handle. Extracting dilute CO2 straight out of the atmosphere is hard, but for the time being there are plenty of places where concentrated CO2 is being emitted and would be easy to get.
We could, of course, just plant trees and harvest the solar energy in the form of firewood.
> I'm not aware of any Mac which will run Catalina and Big Sur but not Monterey so no need to buy a new Mac.
3rd generation Retina Macbook Pro (Late 2013 / Mid 2014) runs Big Sur but not Monterey.
https://en.wikipedia.org/wiki/MacBook_Pro_(Intel-based)
"E2EE essentially encrypts messages at every step of the journey in cross-communications"
That's not well worded.
Essentially it encrypts messages *once* at the start of the journey, and they remain encrypted all the way to the end, where they are decrypted by the recipient.
If you want to break it, it has to go at either endpoint. Phone to Facebook? Capture it at Facebook. Phone to Phone? You have to capture it at one of the phones.
"No-code development tools"? Clearly if they worked, they would already be used - but they aren't.
At the end of the day, this is all down to logic: "when X happens, the system needs to do Y". The complexity is not around implementing that, but all the other things you *didn't* say: what happens if Z also happens? What happens if the customer changes their order before it ships, or the supplier is out of stock, or the credit card company applies a chargeback? What are the exact rules for calculating tax and shipping?
It's all about *process*. If you are lucky enough to find an off-the-shelf package which works roughly in the way your business does, then maybe you can can change your business processes to fit the package. Otherwise you're into the realm of codifying all your processes, the various ways you interact with your customers and your suppliers. Then you need to make sure that it is tested *before* set loose on real customers; and when you change it you don't introduce unexpected behaviour.
A "no code" system can replace chunks of programming language with boxes and lines between them, but it's not going to make any difference to any of the above.
It would be nice to swap the SSD though. I would happily give up any (slight) performance benefit of soldered-on SSD for standard NVMe/M2 slots.
The SSD is the bit which is most likely to fail and need replacing after extensive use. Plus, it's the part that falls in cost rapidly - buying 1TB in 2-3 years time may cost the same as 500G now.
According to the Apple presentation, the ports at the front of the Mac Studio "M1 Max" version are 10Gbps USB-C, not Thunderbolt 4 - although of course the connector is physically identical.
However the "M1 Ultra" Mac Studio has all Thunderbolt ports (4 rear, 2 front).
The not-free cloud is more likely to be around in the morning.
I think the major clouds have reasonable pricing: they're making enough profit to be sustainable, but there's enough competition than none of them can charge excessively. If they did, cloud-to-cloud migrations are possible, albeit time-consuming and expensive.
The smaller players which undercut them - e.g. Wasabi - hopefully still have enough margin, scale and/or investor capital to last. If not, then enjoy the cheap ride while you can.
The wise have a multi-cloud strategy, so they can play off the suppliers when it comes to contract renewal time.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
