Foxboron

16 ms·

151.
by Foxboron 3y ago
vimspector is a cool DSP for vim. https://github.com/puremourning/vimspector/
152.
by Foxboron 3y ago
The 1 Gbit/s uplink for the Tier 0 mirror has been fully saturated for almost 4-5 hours now and I expect servers to be syncing for rest of the day really.
153.
by Foxboron 3y ago
I don't do any of the actual server infra so I don't have all the details. The btrfs raid setup is standardized across all our infra and can be found on ansible. https://gitlab.archlinux.org/archlinux/infrastr
154.
by Foxboron 3y ago
Historical mostly. Github usage predates the Gitlab instance and some projects haven't been migrated. We also keep some repositories on Github as a secondary mirror. We've also had some performance issues on Gitlab for `svntogit`
155.
by Foxboron 3y ago
Well, that is a bit outdated. I think my draft is more detailed: https://wiki.archlinux.org/title/User:Foxboron/GitMigration Runbook for the migration can be found here: https://md.archlinux.org/ut
156.
by Foxboron 3y ago
You could try vimspector. It's main target is vim and not neovim. https://github.com/puremourning/vimspector/
157.
The Mullvad Browser(mullvad.net)
1182 points by Foxboron 4y ago|419 comments
158.
by Foxboron 4y ago
>but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want. No, it implements the verifier API which needs to be disable
159.
by Foxboron 4y ago
They don't really do any source authentication at all. There is no strategy for checking gpg/minisign/whatever signatures and fetching keys to validate these things.
160.
by Foxboron 4y ago
> And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do. This is false. The issue is t
161.
MSI's (in)Secure Boot(dawidpotocki.com)
194 points by Foxboron 4y ago|149 comments
162.
by Foxboron 4y ago
Slight misunderstanding in the blog post there. > Archlinux is 78% reproducible on amd64 packages > Debian is 95.7% reproducible on amd64 packages This references the "fuzzing" infrastructure hosted by the Reproducible Build
163.
Arch Linux in November 2022(monthly-reports.archlinux.page)
3 points by Foxboron 4y ago|0 comments
164.
Coredumpctl, delve and debug packages for Go(linderud.dev)
1 points by Foxboron 4y ago|0 comments
165.
by Foxboron 4y ago
If someone thinks the Hy mascot, Cuddles the Cuttlefish, looks awfully familiar to a certain crustacean mascot, you would be correct! They are both drawn by Karen Rustad Tölva! https://www.aldeka.net/
166.
by Foxboron 4y ago
>I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong. When I was working on Hy, almost 10 years ago, there was a couple of Hy core devs that had managed to push some Hy code into production. I
167.
by Foxboron 4y ago
Hy isn't transpiled though, it's compiled into valid python bytecode so some of the traditional issues around transpilation doesn't apply to Hy.
168.
by Foxboron 4y ago
I'm sorry I don't meet your expected level of professionalism on a random internet forum. Rest assured I have filed a deviation report to my manager.
169.
by Foxboron 4y ago
> I really don’t see how arch fairs any better here, care to elaborate? Arch has spent a considerably amount of time getting to the figure it has and is in the same position as NixOS to maintain reproducible builds. The claim that NixOS
170.
by Foxboron 4y ago
>Nix is 99.77% reproducible, so come on. It’s not marketing, nix just properly solves the problem for the first time ever. You haven't read r13y properly. >1733 out of 1737 (99.77%) paths in the nixos.iso_minimal.x86_64-linux ins
171.
by Foxboron 4y ago
It's not. It's marketing. The focus of Nix is reproducability in the same wain as docker: Same dependencies for the same behavior. They can't guarantee bit-for-bit reproducability any more then your average distribution. Arch
172.
A Report from the 2022 Image-Based Linux Summit(lwn.net)
1 points by Foxboron 4y ago|0 comments
173.
by Foxboron 4y ago
No worries :) I should blog more about these things so people do get better insight into obscure issues like the one above.
174.
by Foxboron 4y ago
Lets not forget that simply using any given build system doesn't magically solve all the issues. If a `make install` invocation gzips manpages instead of the package manager or distro hooks, then you won't have reproducible manp
175.
by Foxboron 4y ago
> Archlinux's PKGBUILD doesn't https://github.com/archlinux/svntogit-community/blob/cf04bef ... > Because of that, "docker version" on arch linux outputs that it was built on the actu
176.
by Foxboron 4y ago
Which package manager would be more reproducible than pacman and Arch? We hover around 85% and 89% reproducible packages across all our packages and no distro, to my knowledge, is close to anything like this. https://reproducible
177.
by Foxboron 4y ago
I think the situation would have been better if the people opposed to Debian would contribute to better init script support then just forking it.
178.
by Foxboron 4y ago
It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate". UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphic
179.
by Foxboron 4y ago
>But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited. This isn't very accurate. When Debian decided to switch to systemd, t
180.
by Foxboron 4y ago
You misunderstand. All the Lenovo laptops I've had are flawless. The issue is the 12th gen Intel board which you can select on some models.

More ›