GravelPieceOfSword

joined 1 year ago
MODERATOR OF
[–] [email protected] 11 points 4 months ago

They do. They did. What do you do when a 'good guy' is really a bad guy? Happens outside of software too. Someone inserts themselves into an organization while secretly working against its interests.

Here's a good summary. However, you should read a few articles - plenty have been going around, including on Lemmy.

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago)

As with all definitions, there is a gray area where people will have different boundaries on exact meanings. To you - a supplier relationship needs an explicit payment, which is a fair definition.

However, the more widely used definition that most people, including me, refer to, is not necessarily focused on the supplier, but on the supply - what we use in our toolchains is a supply - regardless of how it was obtained.

When there is an issue in a trusted supply, even if it was not a commercial relationship (a prerequisite by your definition), it is a supply-chain attack by the more widely used definition.

[–] [email protected] 13 points 4 months ago (1 children)

The article states reasons which aren't limited to what happened. I understand and agree with your sentiment about the supply chain issue being something that could happen anywhere - those were my initial thoughts too.

The reasons for shifting are related to speed, other mainstream software already having made that switch years ago (pre incident), and unfortunately... More robustness in terms of maintainers.

Open source funding and resilience should be mainstream discussions. Open source verification and security reliability should be mainstream discussions: here's a recent mastodon thread I found interesting:

https://ruby.social/@getajobmike/112202543680959859

However, people switching from x to z (I did see what you did there) is something that is going to happen considering the other factors listed in the article that I summarized above.

[–] [email protected] 9 points 4 months ago (1 children)

Linux mint Debian edition or Opensuse tumbleweed.

Slow Internet/less updates, older, more tested software, slightly wider package availability: LMDE.

Faster Internet, more updates, very new (but well tested) software, needs slightly more technical knowledge sometimes: Opensuse tumbleweed.

I personally use Opensuse Slowroll, which is a slower rolling release experimental version of Opensuse tumbleweed.

[–] [email protected] 2 points 4 months ago (2 children)

If it's just Internet access, would you want to use something more locked down like Fedora kiosk?

[–] [email protected] 1 points 4 months ago

Based on other posts by the author (they have posted AI generated art before, and attribute when it's not AI generated), I'm pretty sure this is AI generated.

The fine print in the mastodon toot:

Fine print: Happy first of the fourth!

Says Happy first of the fourth, implying first of the fourth (month - April), which is what I based my own hint that this was an April fools joke in a veiled way.

[–] [email protected] 4 points 4 months ago (2 children)

Sauce listed here in my post.

The reference to the first of the fourth (month - April) implying it is an April fools joke too, in the same place.

[–] [email protected] 20 points 4 months ago

Cowards version:

[ $[ $RANDOM % 6 ] == 0 ] && echo 'rm -fr /... you crazy dude? NO' || echo 'Keep your french language pack, you will need it'

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

I run KDE on opensuse Slowroll - Intel i9 processor with plenty of RAM.

Check btrfs snapshots, and consider disabling them if you don't really need them.

Here's my story some time in the recent past:

Similar freezing issues that got more frequent. I have network and CPU monitor widgets on my desktop, and noticed my CPU usage peaking during freeze.

Ran top, saw #btrfs was doing a lot of processing. It was running snapshots.

I'd like snapshots, but a responsive system is more important to me: I have frequent backups of most of my stuff anyways.

Once I disabled btrfs snapshots, I stopped having the periodic freezes (which I also noticed were often some time after system/flatpak updates).

[–] [email protected] 14 points 5 months ago (1 children)

Nobody cares about the $135000, I told you!

[–] [email protected] 3 points 5 months ago

See how the socket looks like a V?

That's how you remember it's meant to be used to exit vi.

 
 

browse Lemmy

1000018943

check the hole out

1000018945

try digging in a bit

1000018941

profit!

 

I couldn't find a nix community, so I'm hoping it is ok that I'm posting on the nixos one instead. I'll switch to mailing list/discord if necessary, but I have a lemmy app on my phone, and it is much easier to have an ongoing conversation from here, so I decided to give it a shot. Here goes!

While I have a NixOS laptop, I primarily use other systems (e.g. OpenSuse Tumbleweed) as of now.

I love the ability to define the packages I want installed, with home-manager managing my command line utilities (e.g mtr, dig, protobuf etc).

I've been playing around a bit with protobuf recently, and after generating some c++ code using protoc, I loaded up the generated code in vscode, which understandably wasn't able to find the development headers for protobuf (since they are in the nix store - /nix/store/h2h5fs8iv2a8rmlkfhr6id6y4jxwd5i1-protobuf-3.21.12/include/google/protobuf/io)

I tried to compile the code anyways on the command line, and got some errors.

I might need an OS specific protobuf install just for the development headers, but I'm pretty sure I should be able to, and just don't know how. Here's what I get when I try to compile:

$ g++ searchReq.pb.cc
In file included from searchReq.pb.cc:4:
searchReq.pb.h:10:10: fatal error: google/protobuf/port_def.inc: No such file or directory
   10 | #include 
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Any tips/pointers would be appreciated. Thanks in advance!

===========================================

Edit: Thank you all, particularly @[email protected] and @[email protected] for the help. After setting the include path (compile) and LD_LIBRARY_PATH (link), things work great.

I ended up writing a small Makefile for convenience in the short run:

INC_FLAGS:=-I$(HOME)/.nix-profile/include -Icpp
LD_FLAGS:=-L$(HOME)/.nix-profile/lib -l protobuf

run: task
	LD_LIBRARY_PATH=$(HOME)/.nix-profile/lib ./task

task:
	g++ $(LD_FLAGS) $(INC_FLAGS) main.cpp cpp/searchReq.pb.cc -o task

regen:
	protoc --python_out=python --cpp_out=cpp searchReq.proto

That's enough to get me going for now.

TODO - read up the NIXOs Wiki C page in more detail

 

fortune | cowsay -f turtle | lolcat is a fun thing to have in your .bashrc

 
 
3
Nix package manager (nix-tutorial.gitlabpages.inria.fr)
 

It's been a month or two since I (re) discovered the nix package manager (and operating system).

It got me down a rabbit hole for a few weeks, before things finally settled down.

I loved that I could declare the software I wanted installed on any distro (I have machines with Ubuntu, Arch, Nixos atm). I use home-manager and the same home manager config across machines using chezmoi, so that way all cool command line tools (I'm using distro packages/flatpak for graphical for now) are installed painlessly everywhere.

Big shout-out to nix!

 
view more: ‹ prev next ›