Scoopta

joined 2 years ago
[–] Scoopta@programming.dev 6 points 18 hours ago (2 children)

But Linux also has containers and I haven't found a networking setup I can't do with it so while this may be true it seems anecdotal

[–] Scoopta@programming.dev 2 points 1 day ago (1 children)

I'm going to just point out that hating all white males is just as backwards as hating all older generations. Hating anyone for stuff like that is stupid period. Not saying you do, it's just the last sentence feels like you're trying to appeal to people using the same BS you're arguing against.

[–] Scoopta@programming.dev 9 points 1 week ago

You can have a file in 2 folders, they're called hardlinks

[–] Scoopta@programming.dev 13 points 2 weeks ago

And IMO if anything this is Nvidia's doing, arch is just being arch, like it sucks but I also don't see a problem with arch in this instance.

[–] Scoopta@programming.dev 238 points 4 weeks ago (12 children)

Further increase confusion by having error pages where all 3 are green

[–] Scoopta@programming.dev 2 points 1 month ago

Thanks, that is indeed dystopian

[–] Scoopta@programming.dev 8 points 1 month ago (3 children)

Can someone summerize the article, for some reason it thinks I'm using AdBlock despite not and won't let me actually read it

[–] Scoopta@programming.dev 4 points 1 month ago* (last edited 1 month ago)

The very silly argument the FSF is trying to make is that device A is not programmable because the firmware is baked into the HW effectively making it part of the HW rather than a separate entity. Therefore it's a HW limitation and not proprietary software. Device B on the other hand has proprietary software uploaded to it which is not to be allowed under any circumstances and therefore must be neutered. I call it silly because as you so rightfully point out, the firmware blob could be literally the same exact blob, just stored differently

[–] Scoopta@programming.dev 1 points 1 month ago

Yeah, that would be a much more consistent setup and I agree with everything you said here. I just don't understand how being less programmable is good, it isn't, I don't see any world in which it is unless there is truly NO firmware involved and it's pure HW.

[–] Scoopta@programming.dev 3 points 1 month ago (2 children)

This is exactly my sentiment on the matter too. Firmware is not software in practice although it is in theory. Proprietary firmware that can be upgraded is better than firmware burned into a ROM although the FSF disagrees. I personally run nearly 100% FOSS...S as in software, I have no open firmware, I wish I did...but it just isn't realistic at this point in time.

[–] Scoopta@programming.dev 2 points 1 month ago

This is basically the same argument that caused the libreboot vs gnuboot thing and I just personally don't get it. It seems to me like the FSF is letting perfect be the enemy of the good. Having a FOSS driver isn't something to be celebrated it's something to be punished if the firmware isn't also FOSS. Yes, ofc, FOSS firmware is better than closed firmware, but when almost no modern hardware has that as an option, it's not even something you can really vote on with your wallet unless you just run ancient hardware all the time.

It matters because for me, a good chunk of the FOSS benefit is the auditability of code. Being able to make changes is nice and that's the freedom bit, but being able to audit it is also a huge benefit. If the code is not running on the main CPU then the driver on the main CPU can contain possible exploits of firmware using the IOMMU etc so it becomes more tolerable than a closed source driver. Basically a firmware vulnerability effectively becomes a hardware vulnerability as opposed to a driver running with full kernel privileges and no oversight or containment.

 

Are there any currently available RISC-V dev boards that support the H extension for running KVM?

 

TIL that apparently capital one was assigned the entire 2630::/16 block...which is the largest assignment I've seen to date. Does anyone know of other absolutely massive allocations...are there even any others this large?

 

I've been using duckduckgo for years ever since I degoogled but I'm increasingly annoyed by its complete lack of IPv6 connectivity. I use NAT64 and so it works fine but it bothers me to use services that don't have v6. Does someone have a good non-google IPv6 search engine that's privacy respecting?

1
submitted 2 years ago* (last edited 2 years ago) by Scoopta@programming.dev to c/ipv6@lemmy.world
 

I'm curious about something so I'm going to throw this thought experiment out here. For some background I run a pure IPv6 network and dove into v6 ignoring any v4 baggage so this is more of a devils advocate question than anything I genuinely believe.

Onto the question, why should I run a /64 subnet and waste all those addresses as opposed to running a /96 or even a /112?

  1. It breaks SLAAC and Android

let's assume I don't care for whatever reason and I'm content with DHCP, maybe android actually supports DHCP in this alternate universe

  1. It breaks RFC3306 aka Unicast-prefix-based multicast groups

No applications I care about are impacted by this breakage

  1. It violates the purity of the spec

I don't care

What advantages does running a /64 provide over smaller subnets? Especially subnets like a /96 where address count still far exceeds usage so filling subnets remains impossible.

 
 

This has been my setup for a long time now and I have to say I still absolutely love it.

  • Icons: Flat Remix Red Dark
  • Theme: Flat Remix GTK Red Darkest
  • Launcher: Wofi
view more: next ›