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
Static_Rocket
0 Post – 127 Comments
Joined 1 years ago
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 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...
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.
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:
- Refresh your keyring
pacman-keyring --init
pacman-keyring --populate archlinux
- Remove the archlabs section from your pacman.conf
pacman -Syyu- 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
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
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:
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].
[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.
Bitwarden does use a local database and syncs. When you authenticate it unlocks the local database and does regular syncing behind the scenes.
I do recommend self-hosting vaultwarden for the primary server though.
That warning comes up if you are using sd-vconsole but do not have systemd in the mkinitcpio hooks. You should fix that but it is most likely unrelated to the login issue.
Login issues normally hint at either the user shell or pam configs being wrong but you can also get this behavior if (the users home directory is on a secondary disk && that disk failed to mount && you aren't using systemd-homed).
I strive to replace bill. I only work on undocumented code from 3rd parties.
I don't get people being worried about an offline application designed to run one shot as the current user not receiving updates. I do get maintainers dropping the package from package repos now that it is officially archived though...
I've been waiting for the "Avoid tolls" option to pop out of existence one day with no public explanation.
It depends on what you want. Do you want containers that don't blow away your firewall? Podman is nice, but docker can be configured a little to avoid this. Want things that autostart and don't have issues with entry points that attempt to play with permissions/users? Docker or podman as root is necessary. Want reasonable compose support? Podman now needs a daemon/socket. Want to make build containers and not deal with permission/user remapping at all? Podman is really nice.
Do not attempt to use podman-compose. That app is dead.
Unfortunately if you want to make tools that will be used by other people then you must add docker support. It just owns too much of the market.
We do not defend companies in these parts. If everyone's bad then everyone's bad. There shouldn't need to be a "relative to x, y isn't that bad."
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).