LMAO
LMAO
Blueski
Honestly I don’t know what’s up with the mass delusion about Bluesky being oligarch-free. It’s understandable that most don’t know or haven’t looked into it, but then some folks that should know better are displaying the same ignorance.
Absolutely not.
Every time I hear a junior developer say we should rewrite something they have made 0.1 effort understanding, I thank the JS world for not giving a generation or two of developers a well thought out application development framework.
You lost me at shitting on legacy code. My brother in Tux, we don’t rewrite code willy-nilly in the FOSS world either and for a good reason. New code always means new bugs. A shit ton of the underlying code in your Linux OS was written one or more decades ago.
This is because employees in South Korea can “only” work a maximum of 52 hours per week, including twelve hours of overtime. As a result, employees often have to leave work and go home even when important tasks have not yet been completed. For this reason, key employees of the Exynos team are reported to have worked unpaid overtime more and more frequently over the past few years, with the extra hours going unrecorded.
Why is SK’s birth rate in the shitter.
Given everything we’ve seen over theast little while, including the process of non-profits getting taken over by their VC funded subsidiaries; that difference you see is almost certainly a matter of being at a different point in their respective profit timelines.
The author explains in the thread and has links to further info.
It’s a trap.
- A message from Canada
I find the intermediary classification a bit unconvincing and perhaps unintentionally misleading. It sounds like a nice framework to look at the world and it does describe the particular domain alright and it allows for drawing useful conclusions. Unfortunately solving the problems it highlights would produce marginal gains because I think intermediaries as described are just a special case of something more general. Firms of any kind are acting as intermediaries in the exchange of the products of people’s labor. The effects are all the same, these intermediaries make the exchange easier at the expense of keeping some of the labor products from one end or the other, but usually both. It seems to me that the problem of the platform intermediaries power is just a special case of the power of firms over labor. Which really reduces to the problem of the power of capital over labor. If we somehow solve the platform intermediaries problem, we leave the general problem unsolved. And then if we don’t think in terms of the general problem, we can’t even solve the special problem because the tools needed are controlled by capital. That is the lawmakers who could change the law are paid by the powerful intermediaries (firms) and not by the people on either end of the intermediaries. If we hope to ever solve any of this I think we have to look at the world through the general lens and focus on ways to reduce the amount of capital accumulated by firms from people’s labor. Fortunately there are well known solutions for that and they’re actionable for most people.
I see. Makes sense.
This is the right way to optimize performance. Write everything in a decent higher level language, to achieve good maintainability. Then profile for hotspots, separate them in well defined modules and optimize the shit out of them, even if it takes assembly inlining. The ugly stays its own box and you don’t spend time optimizing stuff that doesn’t need optimization.
There’s a WIP VirtIO driver in a PR but it’s not done yet. VMware’s own VMSVGA is open source if I remember correctly. I wonder if they’ll adapt it to KVM and if they do, whether that’ll be usable in KVM without VMware.
If we get VirtIO 3D acceleration in Windows guests from this, I’d be really happy.
The gas products aren’t PTFE though. So it’s unlikely that PTFE entered their blood via this route.
You could use a systemd unit file:
[Unit]
Description=docker_compose_systemd-sonarr
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
WorkingDirectory=/var/lib/sonarr
ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
You’d place your compose file in the working dir /var/lib/sonarr
. Depending on what tag you’ve set for the image in the compose file, it would be autoupdated, or stay fixed. E.g. lscr.io/linuxserver/sonarr:latest
would get autoupdated whereas lscr.io/linuxserver/sonarr:4.0.10
would keep the container at version 4.0.10
. If you want to update from 4.0.10
, you’d have to change it in the compose file.
This is beautiful! It’s like a textbook example for everyone paying attention to draw crisp conclusions for how the system works.