akash_rawal

joined 1 year ago
[โ€“] [email protected] 5 points 4 days ago

We test our code locally, but we cannot test the workflow. By definition, testing the workflow has to be done on a CI-like system.

There is nektos/act for running github actions locally, it works for simple cases. There still are many differences between act and github actions.

It might be possible for a CI to define workflow steps using Containerfile/Dockerfile. Such workflows would be reproducible locally.

[โ€“] [email protected] 60 points 4 days ago* (last edited 4 days ago) (14 children)

Time for the yearly barrage of "Setup CI"..."Fix CI" commits.

That is my experience with basically every CI service out there.

[โ€“] [email protected] 1 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

Windows will not boot with this method. By renaming the file back to bootmgfw.efi windows will boot again but now linux won't boot. There is no clean solution, other than switch to different computer that doesn't have this issue. Because of issues like this I don't recommend dual booting. Installing only Windows or only Linux is more manageable for not-tech-savvy people.

[โ€“] [email protected] 1 points 2 weeks ago (5 children)

In windows EFI partition, there will be an EFI/Microsoft/bootmgfw.efi file, I usually rename it to bootmgfw.efi.bak and that allows grub to load.

[โ€“] [email protected] 1 points 2 weeks ago (7 children)

I have observed that many laptops are hard-coded to boot windows whenever possible. Even with windows bootentry missing, firmware will skip Grub set to first priority and start windows. Only way to make them start Grub is to rename bootmgfw.efi to a different name.

[โ€“] [email protected] 7 points 3 weeks ago

Testcontainers uses 'ryuk' to clean up containers and it needs docker socket mounted within its container to work. So if you had any hardening config that prevents the docker socket access within a container e.g user namespace or SELinux then Testcontainers doesn't work.

And I think it would be nice if Testcontainers 'just worked' with Podman without any additional steps.

[โ€“] [email protected] 8 points 3 weeks ago

Nothing else. Though docker socket issue was important enough.

 

Testcontainers is a library that starts your test dependencies in a container and stop them after you are done using them. Testcontainers needs Docker socket access for mounting within its reaper, so I made a (for now minimal) different library that does not need Docker socket access. It also works with daemonless Podman.

[โ€“] [email protected] 1 points 2 months ago

You have to practice switching between neovim and other editors.

You have forgotten how to use a normal editor. I am not making it up, it is a real phenomenon. Similar to when SmarterEveryDay learned to ride a backwards bicycle he forgot how to ride a normal bicycle and essentially had to re-learn it. You have to re-learn how to use a normal editor.

[โ€“] [email protected] 1 points 3 months ago
  1. It might be a card grabber.
  2. Don't put real card details of course.
[โ€“] [email protected] 1 points 3 months ago

It wants you to put dummy details as fast as you can.

[โ€“] [email protected] 1 points 3 months ago

It is a game, but it might also be a card grabber.

 

I took each rating for games on Wine Application Database, mapped them to numbers (Garbage -> 1, Bronze -> 2, Silver -> 3, Gold -> 4, Platinum -> 5) and plotted a monthly average.

 

I was exploring direct links between machines, and basically failed to break something.

I assigned IP address 192.168.0.1/24 to eth0 in two ways.

A. Adding 192.168.0.1/24 as usual

# ip addr add 192.168.0.1/24 dev eth0
# ping -c 1 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.051 ms

***
192.168.0.2 ping statistics
***
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.051/0.051/0.051/0.000 ms
#

B: Adding 192.168.0.1/32 and adding a /24 route

# ip addr add 192.168.0.1/32 dev eth0
# # 192.168.0.2 should not be reachable.
# ping -c 1 192.168.0.2
ping: connect: Network is unreachable
# # But after adding a route, it is.
# ip route add 192.168.0.0/24 dev eth0
# ping -c 1 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.053 ms

***
192.168.0.2 ping statistics
***
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms
#

Does this mean that adding an IP address with prefix is just a shorthand for adding the IP address with /32 prefix and adding a route afterwards? That is, does the prefix length has no meaning and the real work is done by the route entries?

Or is there any functional difference between the two methods?

Here is another case, these two nodes can reach each other via direct connection (no router in between) but don't share a subnet.

Node 1:

# ip addr add 192.168.0.1/24 dev eth0
# ip route add 192.168.1.0/24 dev eth0
# # Finish the config on Node B
# nc 192.168.1.1 8080 <<< "Message from 192.168.0.1"
Response from 192.168.1.1

Node 2:

# ip addr add 192.168.1.1/24 dev eth0
# ip route add 192.168.0.0/24 dev eth0
# # Finish the config on Node A
# nc -l 0.0.0.0 8080 <<< "Response from 192.168.1.1"
Message from 192.168.0.1
 

Let alone including yourself in the picture. I know how you look like.

Let alone including your loved ones in the picture.

Even when their disappointment of having to face away from the monument is clearly visible in the photo.

And then you make them do stuff like 'hold the sun in your hands' or whatever.

 
view more: next โ€บ