There are not enough words to describe how much I hate Akamai EdgeSuite. So many random validation loops and 403s across different physical computers, different operating systems, different connections and even countries. A couple of services I need use it and it's 30% I'll make it past their stupid "protection".
Despite the HN title (and while the focusing optics are similar), the structure in the article was directly milled with an ion beam (FIB), not electrons.
There is an implicit shame in disgrace but faceless entities have no shame. They'll just put out another press release written in corporate newspeak by an LLM and move on withe the plans anyway. This is standard Google behaviour. They do it with Chrome, they do it with Android, they'll keep doing it with all their captive markets. I fear that in practice even having an "advanced flow" will make little difference as some applications will refuse to work if you have it enabled anyway (in the same vein if debugging is enabled, for example).
Nothing about Android is open except the absolutely minimum amount of linux kernel that's required to boot the thing. Then it's blobs and restrictions all the way to the screen.
Chrome is the dominant browser. Sad as this may be removing it from Blink means de facto removing it from the spec.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
In a lot of cases on a residential line you can't even pay for a public and/or static v4. The option simply doesn't exist. Many ISPs just force you to buy a "business" package for 3x the cost with a bunch of other features you may not need.
Issue (1) has been a long-standing issue and a prolonged back and forth [0,1] between NVIDIA and Xorg/Wayland devs about implicit and explicit synchronisation protocols. It looks like the explicit sync protocol is in the process of getting merged upstream and the 555 series driver [1] will take advantage of this so hopefully things are looking better. Problem with wayland is that all of the driver, xwayland and every compositor must support the new protocol but it looks like mutter, kwin and wlr will eventually support it. That being said there are constantly new paper-cuts appearing with the NVIDIA driver and Wayland support so who knows what will break with the new driver. Definitely not a pleasant experience. I'm not saying that AMD is smooth sailing but at least you don't have to fight the driver at every new release.
I'm afraid (2) will probably never work properly :-(
PrinceXML is expensive but I feel it's worth the money. I've used it to layout several RPGs with Markdown source files and HTML and CSS for templates and styling. RPG layouts can be quite complex with stat blocks and the like and it's handled everything I've thrown at it.
Nothing all that exciting, I'm afraid. The new director of InfoSec must have watched a Cable News Show about supply chain attacks, or something, so suddenly anything with package management - pip, npm, gem, etc - was banned from the official Windows policy. Since his flunkies didn't want to get nailed, they just went ahead and flushed any associated environments/runtimes too. It wasn't super consistent. It was, however, generally a surprise - you'd log in one Monday and whoops! Where'd my Python tooling go?
Now, ok, funny thing. Engineering could just get bare metal laptops, whenever they wanted, then blow the thrice-blessed CentOS image on it, and then do whatever the hell. So what happened - and this probably sounds real predictable - they used the CentOS machines to make all sorts of nutty crap, boxed it up, and then sent it back to their "official" Windows machines, now as a locked-in-amber config that never updates, even if five years later it had like fifty zero days in it and none of the libraries were good anymore.
I understand it took a new director and a LOT of meetings to explain whitelist mirrors for package managers, but I was long gone by then, even if I had a tiny hand in rolling out the demo whitelist mirror on-prem. Man, I had no idea what I was doing . . it still makes me shudder when I think of the things they were asking me to do.
I think that's a relatively simplistic way of viewing this. Although I don't disagree with the core argument, Google will always implement and ship "standards" that fit their business model or their vision of the web. A Chrome API becomes a defacto standard regardless of the state of consensus between engine vendors. Chrome can bulldoze through the standards process because of the massive amount of Chrome installations (and derivatives).
There are standards that have never been fully accepted by Mozilla [0] or WebKit (famously webusb for instance, because of security implications) but they are still in Chrome and now Firefox or Safari are effectively a "worse" browser because they don't support "standard" X that never reached consensus but Chrome implemented anyway. It always starts as an "experimental" feature under a config flag while the supposed discussion is taking place "just to see how it works, promise" before Google decides to remove the experimental flag and ship it. WEI started to play out exactly in the same way but given the massive outrage they decided it was too damaging to keep pursuing it (they still sneakily implemented it in Android WebViews).
So although I don't disagree that, yes Google has certainly improved on some things when it comes to standard processes they have abused their powerful position and continue to do so to push forward whatever they think it benefits them.
If there were peers out there beyond Mozilla, Apple, and Edge, I'd agree more. Safari has long been the web's boat anchor that keeps it from going anywhere. Mozilla has lots of good moments, but they also have been snotty meanspirited aggressive press hounds talking mad shit about sensor support, web USB, web midi, and other really amazing capabilities.
Google has no peers who are pro web. So them not having full consensus on what they do try bothers me not the slightest.
More RAM is always nice but I'm secretly hoping we'll start to see more ECC support in the future. With these humongous modules and even with a teeny tiny bitflip probability corruption chance becomes non insignificant.
Oh yes, I understand that. I only wish that ECC support in general starts getting more traction in consumer electronics. Nowadays (unless you go to super noisy super expensive server hardware) maybe with an AMD processor maybe a motherboard manufacturer will have a 20-links-deep document that says that these ECC modules may be supported, proceed at your own risk, might set your flat on fire, kill kittens etc. When you had a couple of gigs of ram it was probably irrelevant but if you have multiple TB of RAM caching file access ECC should become normalised.
Yea, the biggest downfall of ECC in computers was Intel intentionally disabling ECC in dies uses for the consumer processors and leaving it only for Xeons. As a way of forcefully keeping the market segregated.
AMD otoh has brought ECC to the table in Ryzens without the same shenanigans
I know some people won’t be happy until every laptop has ECC RAM and is super cheap, but the reality is that the demand for ECC RAM is very low. The majority of users would choose the extra battery life and lower price if given the option.
I looked and it's hard. Had to resort to reddit recommendations.
Nice circular reasoning. But nothing will change till we're not vocal enough about ECC benefits and shady pricing. I assure you though, it's not about my happiness :)
There’s lots of off the shelf laptops available with ECC memory, some even in slim form factors.
For desktops the entire Thinkstation lineup has ECC available to option or as standard.
For the higher priced models you cant even order them with non-ECC memory.
I think inline ECC (the module performs the ECC) is mandatory with LPDDR4 (the error rates on current silicon are too high to leave it out), but link ECC (between the CPU and the module) is optional.
Note that link ECC + inline ECC don't give you end-to-end protection, since the controller in the memory module can still flip bits. DDR5 is moving to on-die ECC (which, unlike DDR <= 4's side-band ECC) also isn't end-to-end.
I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely.
This article defines all the terms, but is very vague about what things are mandatory, or how reliable the error correction schemes are. For instance, it carefully doesn't say that SECDED schemes detect all two bit errors, instead it says they detect at least some:
> I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely.
I doubt it will be phased out for servers. I haven't seen anyone reporting that on-die ECC in DDR5 has a reporting mechanism, and reporting on ram errors is important for server reliability.
I really wish we’d just get in-band ECC on normal consumer platforms. That way we’d need no special DIMMs, in applications where ECC was desired it could be enabled and the capacity penalty would be paid, in other applications it could be disabled and no capacity would be lost.
I like this idea. 64gb of ram non-ecc, 48gb in ecc. Dynamic, succinct, and enables more supply chain cross over for not having two (three?) separate DIMM types.
On AMD ECC support is pretty much standard on every chip they make, and always has been. Even my shitty 4-core phenom from over ten years ago on an el-cheapo motherboard supported swapping it's regular DIMMs for ECC ones. You're never going to get ECC "for free" but it would be totally possible for everyone to pay the cost once and just move to ECC-only for everything from now on.
Except intel, the company that brought software-locked hardware features to x86, love to price-differentiate.
Having physical memory segments be different logical sizes at runtime depending on the ECC setting does not sound fun.
Having your system’s available memory fluctuate up and down based on how many segments are currently set to ECC also doesn’t sound fun.
Having developers manually turn ECC off for regions where it’s unimportant sounds like a lot of complexity for a relatively rare use case.
There is in-band ECC in some newer Intel designs, but it’s all or nothing. Adding extremely complexity to memory management to selectively disable it sounds like a lot to ask.
I think your reading depends on thinking "application" means "process", while another reading would be that an application is a particular deployed system, where this setting can be altered e.g. at the BIOS level.
It does, but this particular implementation is local to the module, and cannot be used for secondary purposes in addition to error correction, such as storing tag bits.
As a consumer does that matter? I understand server grade hardware wants the extra monitoring/diagnostic gizmos, but will the memory be corrected with the same efficiency as DDR4 ECC or is it an entirely neutered implementation?
I'm not sold on on-die DDR5 ECC providing protecting.
On-die ECC allowed DDR5 to be competitive with DDR4. Is it really protecting your data at rest if the DDR5 die is running at such tolerances that it's correcting single bit errors from internal signalling issues every transaction? It's only single bit ECC, if something else outside of the die(Cosmic Ray, sudden voltage change, sudden temperature change) induces a bit to flip while the internal circuitry causes a different bit to flip your data is now corrupt.
Is there any intuition about how frequently data-at-rest errors occur vs data-in-flight? Would the native DDR5 ECC get me 90% of the way there or is it so minor as to be effectively meaningless?
I assume it is going to take another decade to fully unwind Intel's ECC market segmentation. Trying to get a sense on if I should pay the ECC tax for my next build. Of course noting that as a consumer, I will probably never notice a flipped bit.
Runtime asserts and invariant checks in software can also help a lot with isolating bitflip errors. With a nice addition of also isolating effects of software bugs.
I don't know if it is significant. Runtime checks tend to focus on small but critical part of the data, like size fields. It usually doesn't check bulk data, like decompressed image data, or code, and it also may not be effective if data is in cache. Furthermore, it will only detect errors, not correct them. Also the performance cost is, I think, much higher than the extra RAM chip. Good coding practice for critical path in software, but clearly, it doesn't substitute for dedicated hardware.
I have had defective RAM, and I got quite a bit of corruption before the first crashes, it is hardly noticeable when it is just a pixel changing color in a picture, but it is still something you don't want. ECC would have prevented that.
I know there is software resistant on random bitflips, like for satellites exposed to cosmic rays, but it is a highly specialized field. It is also a field where they use special chips, typically with coarser (and therefore less efficient) dies that are more resistant to radiation. You leave a lot on the table for that.
ECC is better handled in hardware: most of the time it won’t happen, and the hardware can more easily interrupt the processor so the kernel can correct the problem or signal a fault if it’s not a correctable corruption.
Those only help isolate somewhat predictable errors. Which is rare for what ECC is designed to protect against.
If it’s a random, once in several billion reads/writes issue, it can just stop/identify the bad data from further propagating. Sometimes. That data is still lost.
ECC does forward error correction, which is extremely rare for the type of data protection you’re talking about. and if the data is corrupted in RAM (say when initially loaded/read) before the software can apply FEC, there is nothing the software can do.
I thought that the current wave of compiler correctness checking, zero-cost abstractions, JIT compilers and speculative processor behaviour were all about removing those "unnecessary" runtime asserts and invariant checks to get better performance.
But it does not have a means of reporting ECC triggers to the user from my understanding, which is really one of the most important parts.
When ECC starts tripping on a device outside of completely random times is when you should look into what's going wrong. You may have overheating or failing hardware.
Wikipedia: Unlike DDR4, all DDR5 chips have on-die ECC, where errors are detected and corrected before sending data to the CPU. This, however, is not the same as true ECC memory with extra data correction chips on the memory module.
So I'm not sure how this works, because I'm not sure if "true" ECC is better/worse/same as on-die ECC. A casual googling shows on-die to have more advantages.
