Only into systems you don't control. Not into systems you do control unless you want it baked-in. You'd think those frogs would be boiled by now but those which aren't can still escape the pot to hop from the former towards one of the latter.
Could the down-voters explain their votes? In what does the observation of increased production capacity leading to lower prices insult their sensitivities that they felt the need to press that down-vote arrow? Surely you realise that the market works by balancing supply versus demand until some equilibrium is achieved? That demand partly - but not wholly - depends on price? Is it just that you (plural or singular in case of one person controlling more than one down-voting account) can't imagine a domestically-produced good to lead to lower market prices? If not, what else is it that makes my comment so irksome that it needs to be greyed out?
The media industry has been and for a large part still is beholden to "progressives" and look where that has brought us. The term "media consumption" already points at the problem, this terminology befits the tripe and pabulum which these "media channels" funnel towards the media consumption feed lots, i.e. "consumers". Canned "entertainment" made to pacify and numb the "consumers", "news" channels which make Pravda and Izvestia look like also-runs. It is not a "progressives" vs. "conservatives" problem but a "media industry" one. Fortunately the technology needed to create the product pushed by the "media industry" has become so ubiquitous and cheap that it is now possible for outsiders to create something with the needed production quality to compete with the industry while easily beating it on other metrics like storyline and relevance.
...and then you woke up and realised that Iran never allowed those inspectors to inspect the actually important facilities and started removing inspectors from the country in 2023 under Biden.
During the time of JCPOA (original, between Iran and the P5+1) inspectors had access to where they wanted to go (sometimes with friction, sure) and were able to place tamper resistant / tamper revealing instrumentation, air filters, and spectrometers - effectively creating a data record that could place a stochastic cap on {enrichment level, volume}.
After Trump ripped up that agreement during his first term, withdrawing from the pact in 2018, that was no longer the case - leading to your linked 2023 statement.
The JCPOA was a huge mistake. Even assuming that it truthfully capped enrichment and prevented the development of an atomic bomb, at the same time it enriched the nation and therefore allowed Iran to finance terrorism and ballistic missiles.
That's naive and simplistic. Your counterparty isn't going to agree to a deal if they get nothing in return. "Stop doing nuclear stuff or else" isn't a deal, it's a demand.
And this fiasco proves that the US can't really do enough militarily if Iran just decides they don't want to abide by a deal/demand. Sure, this war was costly and painful for Iran, but they're coming out of it with better terms than they had before the war.
> but they're coming out of it with better terms than they had before the war.
That is precisely the problem. We have not done enough militarily when we clearly had the upper hand in the first few weeks of the war. We sank their boats, destroyed their planes and anti-aircraft batteries and could freely fly all over the country destroying targets at will. The Trump administration has clearly failed to finish what it started and has left Israel and the GCC countries in a worst position than if it hadn't done anything at all. The "deal" is a pathetic outcome.
We should return to combat operations and finish what we started. This is not about invading the country. It is about neutering the regime so that it can't threaten the region and international waterways. The most important aspect of this is bleeding it dry economically by destroying their ability to export oil. Track and sink the "shadow fleet" anywhere in the world, carpet bomb oil production facilities, and destroy bridges and railways that allow trade by land. Make it clear that any damages caused to neighboring countries will be paid for by Iran using their frozen assets.
Biden was elected _after_ Trump broke the deal so it's unclear why you think that tells us anything about what would have happened had the United States honored the treaty.
Not a serious question but I'll give a serious answer anyway.
The last time I worried over which kernel was used in Debian Stable was... never. If I want a more recent kernel I run Debian unstable (Sid) which currently is at 7.0.12 (the current 'stable' kernel where 7.1 is 'mainline') but on my servers Stable (currently 'Trixie') does just fine with its 6.17.3 kernel. Debian 'Forky' will be released somewhere in 2027 with either a 7.0.x or 7.1.x kernel depending on how things go. The current kernel used in 'testing' (which will become 'stable' on the next release) is 7.0.10.
People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:
# Default to trixie
Package: *
Pin: release n=trixie
Pin-Priority: 990
# Very low priority for sid
Package: *
Pin: release n=unstable
Pin-Priority: 100
# Give backports medium priority
Package: *
Pin: release n=trixie-backports
Pin-Priority: 500
Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable:
> People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
Which is just as well, because that's not generally a good idea unless you really know what you're doing:
Granted, the kernel is probably the best thing to do it with, on account of their aggressive stance on compatibility and the narrowness of impact (no .so files in play).
Backports are meant to work well along stable packages, but I agree it's definitely not a good idea to start pulling from sid from trixie (for regular packages, kernel is fine), this is asking for a ruined system.
Chaing priority wholesale is not needed just to install kernel image and might break other packages. Just install kernel image from backports after enabling backports.
> apt install linux-image-amd64/stable-backports
Somehow installing with `trixie-backports` isn't picking up latest kernel for me. Used what is being displayed in `apt search linux-image-7`
> The last time I worried over which kernel was used in Debian Stable was... never.
It was briefly a little annoying to deal with wireguard. But it was only a bit annoying, and then they updated. That's the only time I recall specifically caring.
Yes, when that was a thing I just compiled the wireguard module myself to feed it to the virtual router. It was only needed for a short interval and was thereafter handled by dkms, i.e. no problem.
Nice sim, there's one thing missing though: splitting two sections at the same time. It do this all the time as it can almost double splitting speed when dealing with mid-size logs. Split the log in two halves, making sure to keep the halves close together. Rotate around the splitting block by about 60°, split again hitting both halves at the same time. Do this once more and you've split the log into 6 60° sections, a good size for stacking in the fireplace and also a good section size to be able to light a fire. I split between 5 m³ and 7 m³ of firewood per year which is enough to heat our house and cook our food, have been doing this for about 20 years now so I have some experience. The double-split is a good time saver.
Yes, it is still PHP. Sync speed is mostly fine though, most of the 'slowness' which Nextcloud is known for comes from the sometimes sluggish web interface. Point a fast WebDAV-compatible file manager [1] at a Nextcloud instance to get a better impression of backend speed. Point it at an image directory and you'll see as many php-fpm processes launched as there are thumbnails to process.
[1] https://github.com/mickael-kerjean/filestash is a good web-based example of such a thing, ignore all the guff about needing docker since you can just run the whole thing from a single self-compiled binary. By default it sends some telemetry to the mothership, you can remove that by commenting out the relevant code in server/middleware/index.go, look for the init() function and comment out the endless loop containing telemetry.Flush()
I replaced Memories with Immich running as an external application using the OpenID connect provider app to authenticate Nextcloud users. Immich and Memories seem to aim at more or less the same spot but Immich outpaces Memories nearly everywhere: it is a lot faster and offers far better search features which is the main attraction for me since it makes it possible to actually find that needle in the 160.000+ large haystack.
> it's PHP so your single core clocks will generally be more relevant for latency than multi-core performance, feeding many cores requires a lot of divisble work.
That is more or less built-in when you use php-fpm which launches a flock of instances. Slow things in Nextcloud like thumbnail generation are divided over whatever cores you feed it as long as you make sure to allow for enough php-fpm instances to be launched. It won't make generating a single thumbnail any faster but it does speed up generating lots of them.
reply