PowerShell works on Windows because of WMI, to a first approximation.
Because Windows is tied together through APIs and databases and not text files (unlike Linux), everything is text is not as useful as something that can talk objects. And a lot of Windows is object oriented, from the window message dispatching system through COM and down to NT's object manager.
You mean a website A can have login/auth cookies of website B, D, Z, HK… etc? SOP doesn't work? Or is there some sort of exploit on top of third party cookies? (Just curious. I don't know anout browser dev/etc).
By the way, they don't have just one web apps. They have A, they have K, and apparently a Z – subdomain is webz, or maybe that's actaully A. Not sure.
Yes, it has access to the internal storage mechanisms of the browser.
I used to use Cookie Auto Delete for years. But when I last checked it seemed unmaintained. I log out of all somewhat important services anyway every time I am done.
For important stuff like banking I use Firefox containers.
Yeah, all of them could have their weaknesses and vulnerabilities. I just hope no attacker hits exactly the stack I use...
Personally I only open Firefox on Linux booted from a read only usb. In theory there could be a firmware vulnerability in the CPU that could let it write persistent data to the UEFI firmware, but I hope the possibility is small.
If you think about it there's overlap in what the VAE encodes and main model encodes. Objects at a distance resemble texture and textures zoomed in gain structure. The VAE makes textures more efficiently representable at the cost of reducing the representable space of pixels. So things like tiny text become nonsense scribbles. Working in pixel space, especially with something with recursive or cascaded structure, opens the possibility of using the learnt structure of real writing at a higher level to perfect tiny details that actually cannot be approximated without being obviously wrong.
Time is "just" another dimension. There's temporal continuity between frames, a video VAE would be learning and representing those temporal shifts, but there's nothing to say that e.g. a recursively applied generative model at the pixel level also doesn't learn and represent those things.
As ever, figuring out how to train the thing is the hard bit I expect.
(Handwaving over "textures" here, VAEs encode more like somewhat macro blocks of image whose content is also conditioned on surrounding blocks, rather than tiny patches of patterned pixels.)
(And yes I'm a total imposter layman here, I just see VAEs as seeming to be a crutch that reduce data size - super super helpful of course - but being strictly speaking redundant and inhibiting correct fine detail.)
VAEs don't have to inhibit fine detail, you can trivially increase the channel count like the Flux VAE did, but if you're not careful, that will make training on that latent space much more difficult.
Older models like the SD1.5 work like you mentioned, in large part due to relying on PatchGan which just ensures that individual patches are plausible in isolation. There's nothing preventing a VAE from rendering tiny text with the correct architecture and training. If pushed to an extreme, it could essentially start guessing the letters themselves and write different, but still legible words instead of nonsense scribbles.
MySQL was generally (pre 8) optimized for point queries on primary keys. So rows are stored in the PK index, the PK index is a clustered index. Everything more or less falls out of this.
Sure, I'm only taking about innodb. The join strategies supported before 8.0 (5.7 and lower) were basically nested loop and that's it. Which only really works well for a couple of query patterns: point queries with a handful of joined tables all using indexed FKs, or a big sorted scan over one single table and everything joined to it, with pagination through where clause and sorting all on the primary key, and possibly a straight_join to make sure it doesn't start the execution plan anywhere other than the spine table.
> only really works well for a couple of query patterns
To be fair this probably covered probably 9x% of production queries, like high-selectivity index-covered filters and sorts (with a limit). Even today most planners will still use an inner loop.
It's been interesting to watch how different planners have evolved over the years. SQL Server 7 in 1998 launched with features that MySQL and Postgres wouldn't catch up to until the late 2010s, but they had other features and quality-of-life improvements that made these edge-case optimizations hardly noticable.
10 litres alcohol is about 100 bottles of wine a year (exactly 100 at 13.33% alcohol content).
I drink a lot of wine, but 1 full bottle is too much to have regularly. A half bottle - two generous glasses - is more reasonable, but you'll still feel it the next day. And 10 litres of alcohol puts you at 8 generous glasses a week.
Neither nuclear nor gas or coal will matter any more in a few years. It took California only six years to install 41% of the battery capacity goal it has for 2045[1]. As batteries are becoming part for new solar and wind installations, they will push nuclear and gas out simply by being cheaper and more predictable as an investment.
> they will push nuclear and gas out simply by being cheaper and more predictable as an investment.
Unfortunately, this probably won't work everywhere. Particularly in Northern Europe winter is tough as there's very little sunlight (manageable) and often very little wind (not manageable,as it lasts longer).
Nuclear is an expensive way of solving this problem, but it's carbon neutral which is super important.
Even that would be manageable with enough solar panels and batteries, no? Or is it certain that too much surface area would have to be covered with panels?
Batteries work for 1-2 days right now. These wind breaks can be 1-2 weeks.
Like, to be fair, batteries have improved so much in the last decade that this may be solved, but I'm generally sceptical of one thing that will save us, as I reckon we'll need multiple things to ensure resilience (which is really, really, really important when it comes to core needs like electricity and heating).
Is the need for "pretty large breakthroughs" based on realistic calculations, or are you just guessing? I know that most people subscribe to your position, but I can't say I've really seen convincing analyses that show the numbers:
- What thresholds of $/kWh, charge speed, power density etc. do we need to reach before scaling becomes viable? What are those thresholds based on?
- Where are we now on those metrics, and how did they evolve over the last 2-3 decades?
Still, everyone seems very confident that scaling is non-viable now. But IMO it should be possible to demonstrate the non-viability using the approach above - even if the exact numbers are wrong, the orders of magnitude should be good enough, right?
> Is the need for "pretty large breakthroughs" based on realistic calculations, or are you just guessing?
I'm just guessing. But absent some kind of path to get there, I'd prefer to plan for needing to cover this situation with nuclear or other storage (I feel like pumped storage may make sense, but again haven't done the numbers).
Like, if you're correct then we'll end up with lots of power we don't really need. That's great, as we can use it to decarbonise other parts of the economy, however, if I'm correct and we dont build some kind of baseload/storage solution then we'll be in trouble in the winters, which I really want to avoid.
If you're correct, we'll end up with tons of extra power, since the nuclear plants would have to cover everything on their own anyway! But it would also take unbelievable amounts of money, and thus delay the energy transition by decades. We don't have that much time left.
Instead of guessing, maybe it's worth looking into the numbers?
Nuclear power plants need to be taken offline for multiple weeks to months at a time for refueling and maintenance over their lifespans making them a poor fit for base load without extremely costly redundancy in a small country.
A couple points. No, entire plants aren't taken offline at once typically, individual reactor cores are, and modern designs work to minimize that. They still maintain extremely good uptime, especially if you're comparing them to intermittent renewables. Secondly, Italy isn't super tiny, and you need redundancy for outages and such in any grid regardless of its components.
Cutting out the “and maintenance” bit is misleading.
It’s commonplace for maintenance issues at non CANDU reactors to extend the “refelling” downtime. So no, CANDU can’t stay online for decades without maintenance and instead have similar downtime issues. The major benefit is when manufacturing plutonium due to shorter fuel cycles, but overall CANDU reactors are less cost effective which is why adoption fizzled out.
> So no, CANDU can’t stay online for decades without maintenance and instead have similar downtime issues.
There are several situations:
* refuelling occurs
* maintenance and/or inspection needs to happen
* refurbishment may be desired
Some of these things take downtime, some do not, depending on the design of the reactor and other factors. A blanket statement of "refuelling forces a downtime" is incorrect in many situations. Depending on the maintenance (or inspections) needed, this may or may not need downtime. Refurbishment generally means tearing things apart, so usually means downtime, but if a site has multiple reactors they can be done one at a time, e.g.:
Eh, again, I disagree. As an example: Many CANDU reactors have insanely high availability. Example: Qinshan CANDU Unit 1 only had a planned outage of less than 27 days in 2023. There are many other examples. That is crazy uptime in the world of electricity production. And to be clear, if you come at me with "Oh, what about the major maintenance required every 10+ years?". Thermal (coal/gas) has the same issue.
I had a discussion with ChatGPT about this concern. When comparing a modern EPR (European Pressurized Reactor) to a modern coal or natural gas thermal power plant, the required maintenance cycles look fairly similar. For the nitpickers/tomato throwers (I see you!): I am using EPR because it is state-of-the art for nuclear power, and I am specifically using the term "modern" for thermal power plant because the newest ones (China, Japan) are nearly at the frontier of efficiency possible for that type of electricty production.
Roughly: EPR runs for 18 months, then requires 1-2 months of maintenance (which includes refuelling about one third of its fuel assemblies). A modern coal or natural gas thermal power plant runs 12-18 months, then requires 1 month of maintenance.
Next, I could not resist as other commenters already mentioned it. You wrote: "small country". As the Aussies say: Yeah, no. Italy is 300,000 sq km. That is not small. If compared to the United States, it would be the fifth largest state.
Finally, why does it seem that all discussions about electricity production on HN always devolve into the "Base Load Wars"? For me, it is starting to feel like a meme. (Are there LLM troll bots trained to enter HN discussions and make a bunch of "base load" arguments?) Seriously, can someone please create a text-based role playing game that revolves around a future society locked into eternal "Base Load Wars"? (See: PhD Simulator[1])
But is this the intended maintenance duration, or the actual one? Because the construction of every EPR project has been a disaster. Construction took 20 years in Europe and 9 years in China.
Well, there are only four EPRs in the world. It is too early to say. Frankly, as a non-expert "armchair observer", Finland was dumb for starting the EPR project before the design was finalised.
From what I read no further EPRs are planned and they fully want to go ahead with a streamlined EPR2 design.
I think the problem of the Finns was that they really wanted energy independence and tge inly ones that were on the market were the french. No doubt the frenched used much diplomatic muscle to attract them as a first experiment.
Mutability vs immutability describe the relationship between identity and state. Mutable values retain identity when their state changes. For immutable values, getting a new state requires a new identity, and importantly, existing identities never have their states changed.
Variables can be described by types. That is, a mutable slot referencing a value can be a value itself (a reference to a reference) and we can use subtype relationships to describe it. Variables are covariant when used as inputs (i.e code reads from the variable) and contravariant when used as outputs, and invariant when used as both. You can logically supply a Box to a vet(in Box) routine, and supply Box to catchAndStore(out Box). Substitute `ref X` for `Box` when using a language that can pass variables by reference.
Instead of thinking through all the places in the code the AI is going to have to touch, why not kick off three parallel agents implementing the thing and finding out what they did and the tradeoffs they found?
Planning is essential but it doesn't survive contact with reality. However, AI makes contact with reality cheap! Why not use it to improve designs, by writing the design after a few implementations have already been made?
I'm looking for the places that need to be touched, but that wouldn't occur to me (and maybe not to an AI either) while I'm knee-deep in the code. Seeing where the AI touched isn't going to solve that.
If the feature works, and passes AI auditor agents with various hats (thinking of auth and security in particular), did that code you're not thinking of need to be touched? What effect did it have that cannot be captured in side effects, tests or audits?
If what you said doesn't make the AI think of changing that code, why is it going to make the AI auditor think of testing that code? That's what a gap looks like: Nobody changed it, nobody tested it, but some business constraint is now left in an inconsistent state because some piece got updated and another piece did not.
Here's an example. You updated the code that interfaced with the database. But you forgot to update the stored procedures within the database. As a result, the database is now being put in an inconsistent state with every transaction that uses your new code. That is the kind of thing that a software design doc can help you remember, because it is supposed to make you think through all the stuff.
And if you're going to say "Your business stuff shouldn't be able to get into an inconsistent state", well, there's a lot of businesses that have potential landmines laying around. You can say they shouldn't. You're right, in an ideal world. But in this world, they do, and you have to live and work in the world that we have.
Now, in fairness, a good AI check might turn up that the database was left in an inconsistent state... if it understood the constraints well enough. If. I wouldn't want to gamble my production database on the AI's understanding and testing of all the constraints, though.
When I've worked with systems that had these kinds of characteristics, we had checklists. A long list of "have you thought of X". You can't rely on someone writing a design to think of these things either! You need to have a process, and the process applies whether you dive into the code, dive into the spec, or have an AI dive into either.
It's orthogonal.
To be clear, I'm not suggesting blindly deploying an AI-written spike implementation to production, but rather using it to elicit information for better designs.
The fact that a probe that goes off and modifies tables X, Y and Z to achieve the feature gives information for an AI auditor to look for other uses of X, Y and Z, and discover things humans may miss, because with good guidance and a proper harness, AI is usually more persistent and thorough than people. It can turn search results into a checklist and the harness can track completion, and so on. I am far from convinced that your example would not be found via this route.
Well, yes, I'd expect a checklist to be used as part of creating the design document. If there's a separate auditing tool that also knows about the checklist, yes, that's useful.
But if you're doing a spike, no, don't do a design document for it. How can you? You don't know what the design needs to be yet!
(It made everything worse if you ask me but they did do it.)
reply