Static_Rocket

0.0.0.0/0 0::0/0

You didn't specify it couldn't be in CIDR block notation...

I was working at a company at one point that got a contract to build something I viewed equivalent to malware. Immediately I brought it up to several higher-ups that this was not something I was willing to do. One of them brought up the argument "If we don't do it someone else will."

This mentality scares the shit out of me, but it explains a lot of horrible things in the industry.

Believing in that mentality is worse than the reality of the situation. At least if you say no there's a chance it doesn't happen or it gets passed to someone worse than you. If you say yes then not only are you complicit, you are actively enforcing that gloomy mentality for other engineers. Just say no.

significant economic harm to our company

Oh! I have a solution! Make it a local API you fucking goofs.

The most useful quote to those familiar with the linux boot process:

“An attacker would need to be able to coerce a system into booting from HTTP if it's not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it,” Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. “An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code).”

If an attack needs root then it doesn't matter. Your box is toast anyway. If you're using http boot without verification then you should have seen a MITM attack coming.

Cross platform! You know, accessible across all our platforms

openbenchmarking.org

Bottom for life (or at least until something with more stats comes out)

I want the statistic on how many Google employees use ad blockers now. It's basically a necessity.

To be fair, C predates dependency hell. It was either there or it wasn't. C++ has less of an excuse, but it was just object oriented concepts taped to C so it's no surprise it was also missing dependency management.

Now with cmake, gnu-make, meson, gradel, and the world of metabuild systems that wrap those, nothing will change. It it does, it might as well kick start world war 3.

Yo, they added full page copies now? Gotta give it a spin again

No, no, they've got a point. The architecture of Wayland is much more sane. Because of the way refresh events are driven its also much more power and memory efficient. I'll miss bspwm and picom but man there is a lot riding on simplifying the graphics stack under Linux. The X hacks, GLX, and all the other weird interactions X decided to take away from applications made things non-portable to begin with and a nightmare for any embedded devices that thought GLES was good enough.

I present to you the holy hardware compatibility table:

https://networkupstools.org/stable-hcl.html

Anything not listed there is not worth buying.

Clippy 3.0 incoming...

Finamp's current alpha was a huge surprise to me. I stopped looking at development for a few months and in that time they completely reworked it

Some of them advertised specific performance improvements.

I'm not going to rag on them though. Some of them did have performance improvements and basically created the tools and optimized defaults that propagated to standard distros, allowing the gap to close.

I don't think configuration languages should be turing complete. At that point you're just writing an extension.

You'll need to do 4 things:

1. Refresh your keyring

pacman-keyring --init
pacman-keyring --populate archlinux

2. Remove the archlabs section from your pacman.conf
3. pacman -Syyu
4. Maintenance: https://wiki.archlinux.org/title/System_maintenance#Check_for_orphans_and_dropped_packages

This should be everything. You'll need to be careful with removing packages with no upstream. I'm not sure how archlabs distributed their configuration files but if they were packages you'll have to be selective about what you remove. Ideally you'll slowly drop those configs for your own versions with future upgrades.

Well, when the game is essentially running in a virtual machine with an address translation layer that scrambles the backing memory every few minutes you're lucky the game even runs. Good luck trying to decipher that hell. A few guys have done it, I remember the one dude ranting on Twitter about trying to crack Borderland's 3 back around launch.

And then the follow up which was that Denuvo was basically adding a ~30fps overhead to the game and everyone was initially blaming the devs for releasing unoptimized garbage.

Gabe had it right, piracy is a service problem. And my motto has always been if the game has some garbage like Denuvo, then you couldn't even pay me to take a copy. Not worth the headache.

For desktops it doesn't make much sense, but now everything's so oriented to systemd its actually starting to affect embedded Linux applications... so lets try our best to keep the alternatives alive.

Eh, I welcome the iteration. It gives people a reason to practice and hey, who knows, maybe they'll come up with something neat while rewriting curl or something

Fuck it. Gun it at the brick wall. Jerry's rigging up an emergency break as we speak. Don't mind that the last piece to said break may be missing.

- Man who will probably die before we hit the wall

That wouldn't be accepted as is, but those sound like tunables. They could be exposed as kernel parameters. May be worth submitting the patch as an RFC just to call attention to it.

For people using bash that are thinking "how do I do that":

The bash-complete package adds the _command function for recursive completion on commands that accept other commands with their own arguments. It's what sudo uses last I checked. You can add complete -F _command stfu to your bashrc to link it to the stfu command.

https://man.archlinux.org/man/bash.1#Programmable_Completion

They'd update it, but they are afraid it would no longer work as well

Lol, the nomenclature has always been a bit scuffed. Do you refer to desktop 64bit as x86_64 or amd64? (There's history behind those...)

Dog. I'm an arch user. You can't just say "Arch is easier than Debian" and then in the first part of your argument say:

Yes there is the apt repository but if you want something that's not in there, get ready to read the documentation or follow random guides.

You do realize Arch just frontloads that effort right? It's not any "easier." We embrace the fucking manual. (Arch based distros aside...)

Now if you were praising the simplicity of makepkg and the PKGBUILD syntax then sure. As is, though, this is just a bad take.

WebSub (formerly PubSubHubbub). Should have been a proper replacement for RSS with push support instead of polling. Too bad the docs were awful and adopting it as an end user was so difficult that it never caught on.

I'd also like an industrial drone for dispersing pesticides and liquid based fertilizers.

Yamaha: Would you like it to match your motorcycle?

Even webassembly needs a JS stub loader right now. I still can't believe that's a requirement.

Probably not, most of those sensors work by shining an LED light through the skin and monitoring reflection/scatter as a cheap form of photoplethysmography. Anything capable of absorbing that light, like the pigment used in tattoos, will prevent it from working correctly (at least out of the box, there may be some way to adjust for it but I do not think it would be very accurate).

An infrared sensor could work, depending on the ink type. Unfortunately those are more expensive.

I don't know man, I've always liked the idea of a project outliving me. Though for the sanity of future engineers I hope that is not the case. Today's solutions are usually just tomorrow's problems.

Good video going over practical pros and cons currently:

https://piped.video/watch?v=s6zcI1GrkK4

Lol, changing the country of origin doesn't constitute innovation from a consumer standpoint...

Now if this was using 5nm or chiplit or any of the other buzzwords of the day it could be marketed as innovative in the modern sense of the word.

Realistically there is no innovation left for ARM platforms. They all use the same core schematics. They only control data flow and peripheral IP as a manufacturer, unless they feel like building their own core from the spec (nobody really does that anymore as ARM has been desperately trying to standardize everything). The most "innovation" I've seen has come from stubbornness around keeping legacy bus architecture around instead of adopting AXI (even when all the IP they are trying to use already uses AXI and they keep having to make translation hardware).

Something something furmark

Arch had a patch rolled out yesterday [1][2][3] that switches to the git repo. On top of that the logic in the runtime shim and build script modifier was orchestrated to target Debian and RPM build systems and environments [4].

[1] https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad

[2] https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2

[3] https://security.archlinux.org/CVE-2024-3094

[4] https://www.openwall.com/lists/oss-security/2024/03/29/4

Yep, from kernel/ksysfs.c

/*
 * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
 */

I use it for Data-at-rest Encryption. Not much else though.

Part of the payload was in the tarball. There was still a malicious shim in the upstream repo

Just be a little careful here. There are distro live images that Ventoy does not support. They are rare but they do exist.