EUV is all about the laser. To create the small transistors of 4nm for example, either lithography or some other laser tech, you need to be able to shine a pure light on them of small enough wavelength. EUV is the smallest we can create thus far.
I suppose that the real issue is that EUV is the smallest we can focus thus far. Otherwise we'd be using harder X-rays from things like synchrotron light sources, no?
If I run my application/code v1 right now, I generate data. I expect that if I move to application/code v2, I can leave my data in place and it will automatically apply changes to my data.
I do not get that with postgres. If I am on postgres 16, and I want to upgrade to postgres 17, I want to leave my data folder untouched. When I then start postgres 17, it should just work (tm).
It should also work with code that assumes postgres 16, so I can upgrade my database separate from my application. I can not wait 10 days for a large database to be migrated from 16 to 17 without being able to run it. However, I can wait 10 days before updating my code to support features in 17.
The current upgrade process does not give me such confidence in restoring data and uptime. So I don't upgrade until I really have to.
The most baffling part of it is that at first glance it seems nothing like the Dutch IDEAL system.
The IDEAL system is a replacement for online C2B payments. Rather than entering an incredibly insecure credit card number, the storefront redirects you to your bank, where you safely log in, confirm payment, and get redirected back to the store. It's essentially OAuth for payment. The only annoying part is having to manually select your bank, but even that is now a non-issue with a single unified QR code you can scan in any mobile banking app.
On the other hand, https://wero-wallet.eu/ tells me that Wero is a C2C system, so basically an alternative to Paypal, Venmo, Tikkie, or all the bank-initiated payment request implementations we've seen pop up over the last few years. You can send and receive money via your mobile phone number. So how is this supposed to be like IDEAL?
Reading the FAQs it feels like nothing more than a strictly-worse version of Tikkie, but potentially with an added attack vector for your bank account. In other words, I see very little reason to switch to it.
To be fair, this also happened when Graal was released for Java. Give it another go in 3-6 months, the Graal team will have improved interoperability massively.
It is a chicken (interpreter) and egg (dependencies) problem. You cannot fix the dependency problems without the interpreter. Neither can you release an interpreter with full dependency support.
This is the concept behind combined-cycle generation, where an initial stage (direct natural gas combustion) runs a turbine whose cooling (water) drives a second-stage steam turbine. These can push total efficiency to ~60+%, with an ultimate efficiency of ~90+% possible where a tertiary thermal application which uses low-grade heat (anywhere from ~100--180°C / 212--356°F) can be used for some industrial, food-process, or space-heating applications, called cogeneration.
GE also has numerous offerings in this space, and I've seen trade articles describing this in the past, though I'm not finding any presently.
There isn't some majyckal process by which all thermal energy can be converted to motion (or by extension, electrical generation), but it is possible, with additional complexity and capital equipment, to extract much of it.
In winter I think the plan is to use the heat for district heating.
(which is also kinda interesting since in parts of Switzerland district heating through waste management facilities starts to be a problem due to a reduction of the amount of waste available)
There sure are a lot of mission-critical systems and companies hit by this. I am surprised that auto-updates are enabled. I read about some large companies/services in my country being affected, but also a few which are unaffected. Maybe they have hired a good IT provider.
A k8s variety. By Canonical. Screams production, no one is using this for their gaming PC. Comes with.. auto-updates enabled through snap.
Yup, that once broke prod at a company I worked at.
Should our DevOps guy have prevented this? I guess so, though I don't blame him. It was a tiny company and he did a good job given his salary, much better than similar companies here. The blame goes to Canonical - if you make this the default it better come with a giant, unskippable warning sign during setup and on boot.
If you want to avoid XSS attacks, have you tried a CSP header? I know it is more of an output validation, as you restrict what can happen with external scripts.
You can only fit so many characters in your exploit, often due to max field lengths, unless you can load some external script.
Disabling loading unknown external scripts with CSP significantly reduces possible attacks, including XSS attacks, because you simply don't have the space.
Because you cannot compare between an Apple's iGPU and this chip, while using the same software stack. Because you cannot buy a laptop with this chip and use MacOS.
If they would compare it iwth an Apple iGPU, they'd be comparing two things: the hardware AND the OS, which makes it less clear what is contributing to your benckmark results.
> Because you cannot compare between an Apple's iGPU and this chip, while using the same software stack.
Apple Silicon hardware can run Linux (with unofficial GPU support as of late, although still lacking support for the NPU), and official support for Linux on Snapdragon laptop platforms is supposedly in the works. So we should be able to do a proper comparison as soon as official support is added for both platforms as part of a single mainline kernel release.
Generally this is a correct argument - to compare hardware one needs to use the same OS/software stack. But the argument works the other way around also, if there is no identical software stack possible does it really matter how raw hardware compares? The end user running a game or an application would experience hardware+OS rather than just hardware.
reply