Search
1000 results for “Gentoo_eV”
-
Yes source based distro's have been around since the very beginning - in fact, MCC Interim Linux and #SLS weren't far from that mark, except that they merely tried to make it a bit more convenient by packaging up tarballs to be exploded during installation. And there's always #LFS.
If you think about Slackpkg - and you consider that you can actually re-install the entire system by compiling every single component of the default (full) install with the evocation of a single command, followed by the customization of your entire system by installing every kind of software imaginable through the use of #sbopkg or some other automated, dependency resolving package manager that uses #SlackBuilds (which are downloaded, then exectuted, and subsequently download the latest release of he software package desired, which is in turn compiled, packaged, and exploded) - you actually have a fully source based distro installed on your box.
That's right - Slackware is (can be forced to be) an entirely source based distro installed on your device.
And choosing to convert from a point release to Slackware -current switches you from a point release to a #Rolling_Release distro.
*Debian Testing, aka at this time, Trixie is a rolling release. #Arch_Linux is a rolling release, SourceMage and Lunar Linux are source based distros based on #Sorcerer_Linux, the original fully source based Linux distro released when Linux was only about 8yrs old in 2000, and the #Gentoo or #Funtoo source based Linux distros.
SystemD my ass. That has nothing to do with nothing in that conversation - it's completely non-sequitur and truth be told, most source based distros (Arch, Gentoo) support the type of init system that *YOU CHOOSE. For Debiantards such as myself, well..... There's #Devuan - and that's very refreshing to actually have control over your system again with true init scripts. But I rarely use Devuan, even though I've been associated with the initiative since its inception, after leaving the #Mageia team several years ago.
As I state in almost all of my profiles, I'm a Slacker, since 1993 (Slackware Linux), and I'm also a bit of a #Debiantard. On the BSD side, after leaving #Jolix (386BSD) for Slackware, I've pretty much settled on either #OpenBSD or #Dragonfly_BSD, w/the awesome #HAMMER2 FS. I still have a lot of love for #FreeBSD and of course #NetBSD - where I spend a lot of time in my proper #Korn Shell....
But what the heck does any of this have to do with a comparison of using Gentoo Linux being akin to using SystemD?
I don't like SystemD - but if you're a realist, that doesn't mean you forgo using distros that only have that init tooling. You just roll with the punches and keep following the innovations that support you - NO ONE STILL RUNS WINDOWS XP in production - at least, no one outside of state mental hospitals, that's just insane to do in a forward facing business environment.
But a lot of companies do leverage OpenRC, SysVinit, etc., instead of SystemD - that's not going away, and SystemD itself and Poetering have their own up and coming challengers.
SystemD is (supposed to be, originally) a way to boot your box. Yes, it's indeed encroached upon other landscapes since, but not all of those constructs are even considered by many mainstream distros - it's not a fact of life. Other init systems thrive in the UNIX world to this day and will continue to do so.
Likewise, Source based Linux distros are just one among many distros that exist, and may or may not leverage SystemD as their init systems - to really get a good grasp of this, I recommend doing a few Arch Linux installs - with and without SystemD as the base init system. Heck, even Debian still supports your regular, good old #syslog, and at every turn during your updates, reminds you how to keep it enabled since the whole journalctl crap just isn't as elegant, IMO.
Personally, I think more concurrent options are usually better - space is cheap. Storage no longer costs a dollar a meg. or worse, like it was when I was a kid, a few thousand dollars a meg. That's right... MegaByte - Not TB for penny's!
Okay so now I'm waiting to hear back from the OP and see just what the heck they meant when I got triggered. In the meantime....
Enjoy installing and using #Sorcerer_Linux, or the subesquent forks of it's surviving lineage like #SourceMage and #Lunar_Linux - you're now a part of mainstream source-basedLinux History once you do 🤘 💀 🤘
#tallship #Linux #FOSS #distros #Sorcerer
⛵️
.
RE: https://social.sdf.org/users/tallship/statuses/111957857148746923
-
A Gentoo Flotilla
If you’re used to seeing penguins on land, their speed and grace in the water can surprise. Penguins are even capable of extra bursts of speed through supercavitation. They trap air beneath their feathers and then release it underwater when they need to move faster. Their coating of bubbles reduces their drag and gives them the extra speed to help escape predators like leopard seals. (Image credit: R. Barats/OPOTY; via Colossal)
#flowVisualization #fluidDynamics #fluidsAsArt #penguins #physics #science #supercavitation
-
It's spring time, which means it's time for me to get bored with the operating system on my daily driver and start to re-investigate my options. The oncoming onslaught of age verification laws that look like they were written by badly trained AI is also helping preempt this thought, since Linux distributions will of course be forced to react in some manner.
I'm currently running Project Bluefin, which is an opinionated variation of the Universal Blue project. I'm a fan, and I'm not investigating change because of anything holding me back in the current front.
Ground rules:
- I've run Fedora for almost 2 decades. While I certainly can work in Ubuntu/derivatives, I'd prefer not to simply due to toolset familiarity.
- I know, Arch exists. I don't want to. Did Gentoo before Pentium was a thing and compile time flags actually mattered. Don't need to do that again unless some other compelling reason.
- If I'm going to go all the way in on managing the tool, I'll go all the way to Linux from Scratch. At least that way I've built the OS from ground up, so there's actual benefit to compiling everything from scratch - not imagined performance gains on i7's with 64GB ram.
- If you choose "Something Else," leave a comment with the suggestion and discuss/justify why you think I should move. I'm not against new things, but it won't replace my daily driver "just because, bro."
- Don't do the distro war thing. It was tiring on IRC in 2002, it's exhausting 25 years later. Sell your opinion on it's own merits, not by flaming other things.
Boosts welcome. It'll be a fun time.
#linux #fedora #universalblue #projectbluefin #linuxfromscratch #choices #youdidntreadthisfardidyou #maybedanedid #poll
-
It's spring time, which means it's time for me to get bored with the operating system on my daily driver and start to re-investigate my options. The oncoming onslaught of age verification laws that look like they were written by badly trained AI is also helping preempt this thought, since Linux distributions will of course be forced to react in some manner.
I'm currently running Project Bluefin, which is an opinionated variation of the Universal Blue project. I'm a fan, and I'm not investigating change because of anything holding me back in the current front.
Ground rules:
- I've run Fedora for almost 2 decades. While I certainly can work in Ubuntu/derivatives, I'd prefer not to simply due to toolset familiarity.
- I know, Arch exists. I don't want to. Did Gentoo before Pentium was a thing and compile time flags actually mattered. Don't need to do that again unless some other compelling reason.
- If I'm going to go all the way in on managing the tool, I'll go all the way to Linux from Scratch. At least that way I've built the OS from ground up, so there's actual benefit to compiling everything from scratch - not imagined performance gains on i7's with 64GB ram.
- If you choose "Something Else," leave a comment with the suggestion and discuss/justify why you think I should move. I'm not against new things, but it won't replace my daily driver "just because, bro."
- Don't do the distro war thing. It was tiring on IRC in 2002, it's exhausting 25 years later. Sell your opinion on it's own merits, not by flaming other things.
Boosts welcome. It'll be a fun time.
#linux #fedora #universalblue #projectbluefin #linuxfromscratch #choices #youdidntreadthisfardidyou #maybedanedid #poll
-
It's spring time, which means it's time for me to get bored with the operating system on my daily driver and start to re-investigate my options. The oncoming onslaught of age verification laws that look like they were written by badly trained AI is also helping preempt this thought, since Linux distributions will of course be forced to react in some manner.
I'm currently running Project Bluefin, which is an opinionated variation of the Universal Blue project. I'm a fan, and I'm not investigating change because of anything holding me back in the current front.
Ground rules:
- I've run Fedora for almost 2 decades. While I certainly can work in Ubuntu/derivatives, I'd prefer not to simply due to toolset familiarity.
- I know, Arch exists. I don't want to. Did Gentoo before Pentium was a thing and compile time flags actually mattered. Don't need to do that again unless some other compelling reason.
- If I'm going to go all the way in on managing the tool, I'll go all the way to Linux from Scratch. At least that way I've built the OS from ground up, so there's actual benefit to compiling everything from scratch - not imagined performance gains on i7's with 64GB ram.
- If you choose "Something Else," leave a comment with the suggestion and discuss/justify why you think I should move. I'm not against new things, but it won't replace my daily driver "just because, bro."
- Don't do the distro war thing. It was tiring on IRC in 2002, it's exhausting 25 years later. Sell your opinion on it's own merits, not by flaming other things.
Boosts welcome. It'll be a fun time.
#linux #fedora #universalblue #projectbluefin #linuxfromscratch #choices #youdidntreadthisfardidyou #maybedanedid #poll
-
It's spring time, which means it's time for me to get bored with the operating system on my daily driver and start to re-investigate my options. The oncoming onslaught of age verification laws that look like they were written by badly trained AI is also helping preempt this thought, since Linux distributions will of course be forced to react in some manner.
I'm currently running Project Bluefin, which is an opinionated variation of the Universal Blue project. I'm a fan, and I'm not investigating change because of anything holding me back in the current front.
Ground rules:
- I've run Fedora for almost 2 decades. While I certainly can work in Ubuntu/derivatives, I'd prefer not to simply due to toolset familiarity.
- I know, Arch exists. I don't want to. Did Gentoo before Pentium was a thing and compile time flags actually mattered. Don't need to do that again unless some other compelling reason.
- If I'm going to go all the way in on managing the tool, I'll go all the way to Linux from Scratch. At least that way I've built the OS from ground up, so there's actual benefit to compiling everything from scratch - not imagined performance gains on i7's with 64GB ram.
- If you choose "Something Else," leave a comment with the suggestion and discuss/justify why you think I should move. I'm not against new things, but it won't replace my daily driver "just because, bro."
- Don't do the distro war thing. It was tiring on IRC in 2002, it's exhausting 25 years later. Sell your opinion on it's own merits, not by flaming other things.
Boosts welcome. It'll be a fun time.
#linux #fedora #universalblue #projectbluefin #linuxfromscratch #choices #youdidntreadthisfardidyou #maybedanedid #poll
-
It's spring time, which means it's time for me to get bored with the operating system on my daily driver and start to re-investigate my options. The oncoming onslaught of age verification laws that look like they were written by badly trained AI is also helping preempt this thought, since Linux distributions will of course be forced to react in some manner.
I'm currently running Project Bluefin, which is an opinionated variation of the Universal Blue project. I'm a fan, and I'm not investigating change because of anything holding me back in the current front.
Ground rules:
- I've run Fedora for almost 2 decades. While I certainly can work in Ubuntu/derivatives, I'd prefer not to simply due to toolset familiarity.
- I know, Arch exists. I don't want to. Did Gentoo before Pentium was a thing and compile time flags actually mattered. Don't need to do that again unless some other compelling reason.
- If I'm going to go all the way in on managing the tool, I'll go all the way to Linux from Scratch. At least that way I've built the OS from ground up, so there's actual benefit to compiling everything from scratch - not imagined performance gains on i7's with 64GB ram.
- If you choose "Something Else," leave a comment with the suggestion and discuss/justify why you think I should move. I'm not against new things, but it won't replace my daily driver "just because, bro."
- Don't do the distro war thing. It was tiring on IRC in 2002, it's exhausting 25 years later. Sell your opinion on it's own merits, not by flaming other things.
Boosts welcome. It'll be a fun time.
#linux #fedora #universalblue #projectbluefin #linuxfromscratch #choices #youdidntreadthisfardidyou #maybedanedid #poll
-
It took me almost 3 hours but #PipX 1.6.0 is now in #Gentoo, with an updated test shim that makes it possible to test using fake wheels and is only 70 KiB (vs. upstream that uses ~160 MiB for every single implementation).
What's more important, this time it isn't a handmade proof-of-concept anymore but a proper script with instructions that can be used to easily deal with future releases.
-
@raven @RecurringBloatware @probono Same story, I used different monitors (CRT 17" iiyama, some Samsung 17", Benq XI2420z 24", 2k panel from some HP EliteBook in my laptop and tons of secondary displays and projectors), various OSes and distros (Slackware, Debian, Linux Mint, Oracle Linux, Devuan, Gentoo, FreeBSD, etc) and various video cards (old Palit with AGP bus😃, GTX 760 Ti and Intel GMA X950/X3100).
Also I've installed a lot of Linuxes on my previous work and for some friends too :drgn_happy:
And I never saw something like that people posting when speaking about "screen tearing". Tend to think that despite the problem exists — it isn't so widespread as people like to claim :drgn_sigh:
-
I tried a bit more Linux distro investigation, and I think I just should have listened to @hipsterelectron in the first place.
TL;DR: If you want to run Linux without systemd, with something other than GNOME as a desktop (which is implied if you don't want systemd), and if you're comfortable with using the command line for installation, Alpine Linux is a great choice. The default install has zero systemd.
Yes, it's a command-line install, but it's far easier to install than Gentoo. The core OS install was so fast that I thought it had failed. Once I had that sorted and had installed a few support items, the setup-desktop script installed the whole of KDE and Wayland in a couple of minutes. I rebooted and everything worked. It even got the high DPI screen's resolution right for both KDE and sddm, which literally no other distro I've tried has managed.
A lack of bloat doesn't just make Alpine good for containers, it's also really responsive in general use. (Which is how computers ought to be with modern hardware.)
The package manager is nice. Think APT, but much faster. It automatically keeps a separate record of what you've actually asked to install versus dependencies that were dragged in, for easy automatic bloat removal.
Downsides:
- No proprietary Nvidia driver available, you need to use nouveau, so no CUDA or high performance gaming.
- Documentation (including installation) is scattered in pieces on a wiki.
- A lot less stuff prepackaged for you than Debian. Check https://pkgs.alpinelinux.org/ to see if things you need are available.
- You'll need to get used to some things being different thanks to use of busybox, no sudo, no bash by default, and so on.My conclusion: Command line user? Try Alpine. Everyone else? Use Debian, and hope they move away from systemd.
I might revise this opinion if things break a lot during regular updates (hello Fedora), time will tell. #AlpineLinux #Linux
-
CW: New multi-implementation DNSSEC validation DoS vulnerabilities - CVE-2023-50387 ("KeyTrap"), CVE-2023-50868 (NSEC3 vuln)
(living doc, updated regularly - if you prefer a low-edit post to boost, use https://infosec.exchange/@tychotithonus/111926621712441626)
Looks like DNS-OARC coordinated fixes in advance, but no centralized analysis at first other than the announcement from the team who discovered KeyTrap:
Press release: https://www.athene-center.de/en/news/press/key-trap
Technical paper (released 2/15): https://www.athene-center.de/fileadmin/content/PDF/Technical_Report_KeyTrap.pdf
DNS-OARC dns-ops announcement: https://lists.dns-oarc.net/pipermail/dns-operations/2024-February/022436.html
RIPE blog post by one of the authors: https://labs.ripe.net/author/haya-shulman/keytrap-algorithmic-complexity-attacks-exploit-fundamental-design-flaw-in-dnssec/
Apparently builds on this 2019 vulnerability (h/t letoams @defcon.social):
https://
essay.utwente.nl/78777/
Details may be still partially embargoed until patching ramps up.
Analysis:
DoS of all major DNSSEC-validating DNS resolvers (servers, but also maybe local resolvers like systemd's?) at the implementation level. Exploitation described as 'trivial'. Both are CVSS 7.5. DNS is a rich ransom target - but some resolver setups don't even validate DNSSEC.
"In 2012 the vulnerability made its way into the implementation requirements for DNSSEC validation, standards RFC 6781 and RFC 6840" (per ATHENE)
Per the Unbound writeup, both vulns require query to a malicious zone (which is probably not hard to trigger, for any DNSSEC-enabled client or server).
Resolution: patch (recommended); disable DNSSEC validation (discouraged, but can buy you time / mitigate active DoS)
Fixes mitigate the exhaustion by putting caps on validation activities. These caps appear to have been missing from most implementations.
Details:
Two DNSSEC DoS CVEs:
CVE-2023-50387 ("KeyTrap"): "DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers" (CVSS 7.5)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
https://seclists.org/oss-sec/2024/q1/125(KeyTrap was discovered by ATHENE - their press release here has very important detail:
https://www.athene-center.de/en/news/press/key-trap)CVE-2023-50868: "NSEC3 closest encloser proof can exhaust CPU" (CVSS 7.5)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HMITRE links (now populated):
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-50387
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-50868Vulmon queries:
https://vulmon.com/searchpage?q=CVE-2023-50387
https://vulmon.com/searchpage?q=CVE-2023-50868VulDB:
https://vuldb.com/?id.253829Resolver status:
BIND (patched - vuln since 2000?):
https://fosstodon.org/@iscdotorg/111924416653890048
https://kb.isc.org/docs/cve-2023-50387
https://kb.isc.org/docs/cve-2023-50868
https://seclists.org/oss-sec/2024/q1/125
https://www.isc.org/blogs/2024-bind-security-release/
(note: posts say "Versions prior to 9.11.37 were not assessed." but also have a range of affected versions starting at 9.0.0 - typo?)BIND tools:
dig: no validation
kdig: no validation
delv: affected, patcheddnsmasq (patched - 2.90 has fix):
https://thekelleys.org.uk/dnsmasq/CHANGELOG
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q1/017430.htmlKnot (patched in 5.7.1):
https://www.knot-resolver.cz/2024-02-13-knot-resolver-5.7.1.html
(kzonecheck also affected, patched?)ldns-verify-zone:
affected per ATHENE paperOPNsense (patched):
https://forum.opnsense.org/index.php?topic=38939.msg190655#pfSense:
(Bundled Unbound: plan appears to be to make a separate package available for manual update?; BIND: optional package)
https://forum.netgate.com/topic/186145/unbound-cve-2023-50387-and-cve-2023-50868/1
https://redmine.pfsense.org/issues/15256Pi-Hole (uses dnsmasq - patch available)
https://www.patreon.com/posts/dnssec-fix-98498055
https://pi-hole.net/blog/2024/02/13/fixing-two-new-dnssec-vulnerabilities/PowerDNS (patched - all versions affected):
https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6-4-9-3-5-0-2-released
https://github.com/PowerDNS/pdns/pull/13781
https://github.com/PowerDNS/pdns/pull/13784
https://seclists.org/oss-sec/2024/q1/130Stubby:
[?]
https://github.com/getdnsapi/stubbysystemd.resolved:
[?]Ubiquiti
[?]Unbound (patched - vuln since Aug 2007):
https://nlnetlabs.nl/news/2024/Feb/13/unbound-1.19.1-released/
https://nlnetlabs.nl/downloads/unbound/CVE-2023-50387_CVE-2023-50868.txt
https://seclists.org/oss-sec/2024/q1/126Library status:*
dnspython (GitHub patched):
affected per ATHENE paper
https://github.com/rthalley/dnspython/commit/a1a998938b7370dae41784f8bc0a841dc2addba9getdns (used by stubby - no patched release?):
affected per ATHENE paper
https://getdnsapi.net/releases/ldns (not yet patched?):
affected per ATHENE paper
https://github.com/NLnetLabs/ldnslibunbound (used by Unbound):
affected per ATHENE paper
no recent patches?
https://github.com/NLnetLabs/unbound/tree/master/libunboundCloud status:
Akamai:
https://www.akamai.com/blog/security/dns-exploit-keytrap-posed-major-internet-threatCloudflare:
https://blog.cloudflare.com/remediating-new-dnssec-resource-exhaustion-vulnerabilitiesGoogle DNS:
(stated as patched in Register and SecurityWeek articles)
[?]NextDNS (patched per forum reply):
https://help.nextdns.io/t/h7yxwc5/does-dnssec-security-hole-keytrap-cve-2023-50387-affect-nextdnsOS status:
Debian:
BIND:
https://lists.debian.org/debian-security-announce/2024/msg00028.html
pdns-recursor:
https://lists.debian.org/debian-security-announce/2024/msg00033.html
Unbound:
https://lists.debian.org/debian-security-announce/2024/msg00027.htmlFedora:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e24211eff0FreeBSD:
https://cgit.freebsd.org/ports/commit/?id=58e048cad653819eebf91af5840e4b00f155bb1bGentoo:
https://bugs.gentoo.org/show_bug.cgi?id=CVE-2023-50387Mageia:
https://bugs.mageia.org/show_bug.cgi?id=32846OpenBSD (unwind):
Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2023-50387
https://access.redhat.com/security/cve/CVE-2023-50387
https://access.redhat.com/security/cve/CVE-2023-50868SUSE:
https://www.suse.com/security/cve/CVE-2023-50387.html
https://bugzilla.suse.com/show_bug.cgi?id=1219823Ubuntu:
https://ubuntu.com/security/CVE-2023-50387
https://ubuntu.com/security/CVE-2023-50868
https://ubuntu.com/security/notices/USN-6633-1Windows (Server, DNS Role):
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-50387Package status:
BIND:
https://repology.org/project/bind/versionsdnsmasq:
https://repology.org/project/dnsmasq/versionsUnbound:
https://repology.org/project/unbound/versionsGitHub:
https://github.com/advisories/GHSA-8459-gg55-8qjjGo (Knot module?)
https://github.com/golang/vulndb/issues/2552Non-coverage: (no mentions known yet)
AWS :
[?]Azure (Microsoft Server DNS?):
[?]Cisco Umbrella:
https://umbrella.cisco.com/blog [?]CoreDNS:
https://coredns.io/blog/ [?]Infoblox:
https://blogs.infoblox.com/ [?]Quad9 DNS:
https://www.quad9.net/news/blog/ [?]News/Press/Forums
https://pducklin.com/2024/02/18/the-scary-dns-keytrap-bug-explained-in-plain-words/
https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/
https://www.securityweek.com/keytrap-dns-attack-could-disable-large-parts-of-internet-researchers/
https://news.ycombinator.com/item?id=39372384
https://www.darkreading.com/cloud-security/keytrap-dns-bug-threatens-widespread-internet-outages
Detection/Validation:
Check to see if a server is doing DNSSEC validation (if not an open recursive resolver, you may need to query a zone the server is authoritative for):
# zone signed, server DNSSEC-enabled:
$ delv example.net @8.8.8.8
; fully validated
example.net. 4437 IN A 93.184.216.34
example.net. 4437 IN RRSIG A 13 2 86400 20240225232039 20240204162038 18113 example.net. 94G2PRXins1G9ntfklvCq2mvcgqjB0z9FqQXp77lD/wXR4J3D67ceih1 yNgsYYqlIAOoWKXUekux6Zq9aIwszQ==
# zone unsigned, server DNSSEC-enabled:
$ delv google.com @8.8.8.8
; unsigned answer
google.com. 100 IN A 142.250.69.206Tenable:
https://www.tenable.com/plugins/pipeline/issues/165587Snyk:
https://security.snyk.io/vuln/SNYK-UNMANAGED-BIND-6245755Exploits:
(multiple sources describe as "trivial")
https://github.com/knqyf263/CVE-2023-50387 (not tested)
#keytrap #nsec3 #CVE202350387 #CVE202350868 #CVE_2023_50387 #CVE_2023_50868
#dns #dnssec -
Hirn sein komisch.
Plötzlich muss ich an Lehmanns Online Bibliothek denken und an all die #SuSE-Editionen, die ich damals dort bestellt hatte.
Bevor ich keine Lust mehr auf #yast als gui statt als ncurses hatte, weil ich für eine graphische Systemsteuerung auch Windows hätte nutzen könnte. Ich bin dann auf #gentoo umgestiegen. Beste Entscheidung ever!
-
#RSSGuard it is (thanks, @cybertailor).
It looks like something the cat thrown up, it is completely unresponsive while updating feeds (if you touch it, it even stops showing progress) and has insane locale-dependant date formats.
However, it doesn't need WebKit and after fighting its completely counter-intuitive way of resizing the headers (maybe that's a Qt thing) it finally shows me what I need and lets me do things more efficiently than #Liferea did.
-
@danyspin97 But also agreed on the to-each-their own point. I feel like I've moved *somewhat* far up the power/simplicity curve, but would still be interested in going further. Maybe #void, maybe #obarun, maybe even #gentoo if I'm feeling bold.
Something to look forward to, anyway
-
I tried #Box64 on my #MNTReform with #BananaPiCM4 yesterday. It's surprising how fast it is. #LoopHero and #WorldOfGoo are running pretty well, for instance.
I also tried #Parkitect and #ValhallaHills, but those weren't really playable. Valhalla Hills only rendered its UI, everything else was black (probably needs OpenGL features missing in #Panfrost), and #Parkitect crashed frequently.
Now I wonder if #Gentoo #Crossdev can be used for building/running #Box86?
-
Gentoo Linux: because who doesn't love spending New Year's Eve compiling their entire OS from scratch? 🎉🔧 Let's celebrate 2026 by pretending Gentoo is still relevant, while the rest of the world enjoys systems that just work™. 😂💻
https://www.gentoo.org/news/2026/01/05/new-year.html #GentooLinux #NewYearsEve #CompilingFromScratch #TechHumor #JustWorks #HackerNews #ngated -
realized I never did an introduction post even for my other fedi account, so here we are now :neofox_blep:
uhhh hi, I'm Ayzee (she/it)! I also use other names, which you can find on my pronouns.cc page (link in bio). I'm currently trying out Sharkey after using Mastodon for a while.
AuDHD and depression occupy my mind and won't leave even when I ask nicely. I have done programming in systems dev, and am into TTRPGs, drawing, and storytelling. Tone indicators are very nice (/gen).
I run Gentoo, Zsh, NeoVim, Niri, and Kitty. They're all very nice projects and make using a computer rather pleasant (minus the fact I have an Nvidia GPU).
I am certified Based™️ by the World Gender Anarchist Society, and I will be stealing all of the estrogen from cis women (/sarc).
my other account is @[email protected] if you're interested in that one.
#Introduction #IntroductionPost #Queer #Trans #Transfem #Linux #GentooLinux #TTRPG -
Sometimes it makes sense to act smart rather than brute-force.
For example, when Intel makes another #MKL release and you get version like "2026.0.0", and you need to figure out the remaining "-n" suffix for the .deb packages. And you really don't want to start a Debian container to figure that out.
Well, you could just keep brute-forcing until you find the right number. Or you can figure out that the index URL is https://apt.repos.intel.com/oneapi/dists/all/main/binary-amd64/Packages.bz2 and find out that the correct number is 908…
Thanks to @thesamesam for finding the spec. My search-engine-fu would only come up with completely useless guides to newbies. Even after adding the f-word.
The spec's at https://wiki.debian.org/DebianRepository/Format.
-
Sometimes it makes sense to act smart rather than brute-force.
For example, when Intel makes another #MKL release and you get version like "2026.0.0", and you need to figure out the remaining "-n" suffix for the .deb packages. And you really don't want to start a Debian container to figure that out.
Well, you could just keep brute-forcing until you find the right number. Or you can figure out that the index URL is https://apt.repos.intel.com/oneapi/dists/all/main/binary-amd64/Packages.bz2 and find out that the correct number is 908…
Thanks to @thesamesam for finding the spec. My search-engine-fu would only come up with completely useless guides to newbies. Even after adding the f-word.
The spec's at https://wiki.debian.org/DebianRepository/Format.
-
Sometimes it makes sense to act smart rather than brute-force.
For example, when Intel makes another #MKL release and you get version like "2026.0.0", and you need to figure out the remaining "-n" suffix for the .deb packages. And you really don't want to start a Debian container to figure that out.
Well, you could just keep brute-forcing until you find the right number. Or you can figure out that the index URL is https://apt.repos.intel.com/oneapi/dists/all/main/binary-amd64/Packages.bz2 and find out that the correct number is 908…
Thanks to @thesamesam for finding the spec. My search-engine-fu would only come up with completely useless guides to newbies. Even after adding the f-word.
The spec's at https://wiki.debian.org/DebianRepository/Format.
-
Sometimes it makes sense to act smart rather than brute-force.
For example, when Intel makes another #MKL release and you get version like "2026.0.0", and you need to figure out the remaining "-n" suffix for the .deb packages. And you really don't want to start a Debian container to figure that out.
Well, you could just keep brute-forcing until you find the right number. Or you can figure out that the index URL is https://apt.repos.intel.com/oneapi/dists/all/main/binary-amd64/Packages.bz2 and find out that the correct number is 908…
Thanks to @thesamesam for finding the spec. My search-engine-fu would only come up with completely useless guides to newbies. Even after adding the f-word.
The spec's at https://wiki.debian.org/DebianRepository/Format.
-
Sometimes it makes sense to act smart rather than brute-force.
For example, when Intel makes another #MKL release and you get version like "2026.0.0", and you need to figure out the remaining "-n" suffix for the .deb packages. And you really don't want to start a Debian container to figure that out.
Well, you could just keep brute-forcing until you find the right number. Or you can figure out that the index URL is https://apt.repos.intel.com/oneapi/dists/all/main/binary-amd64/Packages.bz2 and find out that the correct number is 908…
Thanks to @thesamesam for finding the spec. My search-engine-fu would only come up with completely useless guides to newbies. Even after adding the f-word.
The spec's at https://wiki.debian.org/DebianRepository/Format.
-
Another curious #portability pitfall: #UTF-16, UTF-32, UCS-2 and UCS-4 encoding are byte order dependent. That is, they can either be encoded as big endian or little endian. #Python uses the host byte order when encoding, and writes a Byte Order Marker at the beginning of the file. When decoding, it transparently reads the BOM back to determine the encoding, so everything works fine out of the box.
Problems start happening when you start comparing the exact byte-level output, e.g. by comparing a UTF-16 bytes read from a file with the result of `encode()`. If the file was written on a little endian system (which is commonly the case), and the test is running on a big endian system, you're suddenly going to get different strings!
The "obvious" way to solve this is to force a specific endianness, e.g. use `utf-16-le` rather than plain `utf-16`. However, when you force endianness, BOM is no longer used — so the byte-level data mismatches on the missing BOM now. The trick is, to add the BOM (`\ufeff`) straight into the #unicode string.
https://github.com/python/importlib_resources/pull/313/files
-
Wow. I find this scrying back to 26 May 2021
I scry, with my little eye..
Enjoy the stroll down memory lane, but a dark day it was
___
Freenode Commits Suicide - Evacuations Underway - Breaking News!
[**PLEASE BOOST**]
A few hours ago, under the direct intervention of the Crown Prince Andrew Lee of South Korea, beginning with about 700 IRC channells, Freenode staff began hijacking and purgings all channels that had mention of "Libera" in their channel topic.
https://www.devever.net/~hl/freenode_abuse2
More details in a minute, but first, just a short list of the sort of channels that have been seized by Mr. Lee in what can only be described a suicidal and vindictive usurpation of some of the most prominent names in the world of computer software:
#wikipedia
#intel
#python
#ubuntu
#rust
##linux
#openbsd
# fosdem
#clearlinux
The Gentoo channels, Haskel, Weechat, etc., etc., ad nauseum...
Basically, the pillars of the software world, Linux, C, major Fortune 500 companies - you name it. POOF!
Earlier articles on the subjects of what has been widely characterized and regarded as a hostile takeover of freenode in the Media were published here over the course of the past few days and fortunately, our registered projects with freenode and Libera were previously announced as having been secured as well.
Only one of our channels has been affected, because the second wave of hijacking was administered by what we can only presume to be a misbehaving, poorly configured bot, in that it seized ownership of channels that merely had mentions of the string "Libera" or "Libera.Chat" by anyone in the channels.
We received the following **Apology** from Andrew Lee with this statement, at 21:15:30hrs PST, posted directly in one of our channels affected by this second wave of hijackings:
<snip>
-rasengan- [Global Notice] In the recent policy enforcement, some channels were erroneously included. We greatly apologize for the inconvenience. Please contact us in #freenode-services or [email protected]. Thanks for your patience and choosing freenode!
</snip>
To that we say, Fuck you freenode, and Fuck you very much Andrew Lee - go eat a fucking dick you punk ass bitch!
By tomorrow, the usual news media outlets will have published freenode's Obituary.
I'm going to post more discussion links to follow below, but suffice it to say that the Earth is indeed flat for freenode, and that ship has sailed over the edge into the abyss.
In the meantime, we urge everyone who has long standing friendships and associations with others still there to find them, and let them know where you'll be following the vacuum left after this implosion.
R.I.P. freenode
https://mastodon.sdf.org/@kline/106299403921451814
https://pleroma.envs.net/notice/A7d3VZuH1myJ6gJS2C
<snip>
comparison of channels that have had their topics forcibly changed to reflect that they remain the official channels for registered projects (Libera string removed from topics):
https://archive.is/uHw1g
https://netsplit.de/channels/?net=freenode&chat=libera&num=100
</snip>
https://www.teddit.net/r/haskell/comments/nl74hc/freenode_has_unilaterally_taken_over_haskell/
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=freenode&sort=byDate&type=story
Twatter is litterally on fire, it's such a mess that I just selected some random post that embodies the type of activities going on there:
https://nitter.fdn.fr/Slatzism/status/1397468106918928386
It's total and complete fuckery.
#tallship #Vger #freenode #libera #irc #FOSS #andrew_lee #fuckery
⛵
.
2021-05-26 01.14.55 twitter.com… -
I suppose I could use my experience to give some #PEP517 build system recommendations.
For pure #Python packages:
1. #flit_core (https://pypi.org/project/flit-core/) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).
2. #hatchling (https://pypi.org/project/hatchling/) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in #Gentoo).
For Python packages with C extensions: #meson-python (https://pypi.org/project/meson-python/) — which combines the power and correctness of meson build system with good very Python integration.
For Python packages with Rust extensions: #maturin (https://pypi.org/project/maturin/) — which is simply a good builder for precisely that kind of packages.
Now, I strongly discourage:
A. #setuptools — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.
B. #poetry-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).
C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.
-
Some time ago two #PEP517 build systems introduced #PyPI trove classifier verification. At a first glance, it makes sense. After all, if you made a mistake somewhere, you'd rather know early than when you try to upload the package. The problem is, that the verification fires for people building packages locally too — including #Gentoo users.
Now, this function was based on the #Python "trove-classifiers" package. Whenever a new classifier is introduced, a new release of the package is made. When you're building a package using tools such as `build` or `pip` (isolated build), the newest version of this package is being installed from the Internet. On the other, a Gentoo user may have an old version, unless we enforce an upgrade via package dependencies. Then building packages that use newer classifiers will fail, and with a confusing message too. Confusing because: 1) contrary to the message, the classifier is valid; and 2) even if it weren't, it doesn't affect us in any way.
And so we asked for an ability to disable this. While it took some time, the #Hatchling showed understanding and eventually merged my patch. On the other hand, the #setuptools maintainer… well, started a long and tedious debate that resulted in ignoring the trivial solution to the actual problem (as "unnecessary complexity"). Instead, we were given another option: we could entirely disable `pyproject.toml` validation. It's not really acceptable, for two reasons: 1) because setuptools actually rely on this validation (so removing it could result in broken package installs instead of an error, if the file is not valid), and 2) because it produces an awful warning on every package build. So we'd end up bullying Gentoo users with false warnings, and some of them would probably end up filing invalid bugs to various upstreams.
The bottom line is: don't use setuptools.
https://github.com/pypa/hatch/issues/1368
https://github.com/pypa/setuptools/issues/4459 -
How to politely point out that somebody's #PEP517 build system is utter #NIH? Here's one whey… err, way:
https://github.com/repo-helper/whey/issues/52
And yes, it's complete NIH, with a dependency on ConsoleKit (seriously?!), a bunch of NIH packages, and a stale bot. On top of that, it's practically used only by its author.
So why do I care? Because the same person also made hatch-requirements-txt #Hatchling plugin, and said plugin depends on NIH packages (of course it does) using whey. So yeah, another case of making one potentially useful package (actually, I don't consider it useful, but random projects depend on it now) and using it to force your NIH projects on everyone.
-
Getting bored with Ubuntu (and annoyed by Snaps, lol). Which distro should I switch to?
Feel free to suggest something else, though I'm not really interested in going back to something super technical like Gentoo, Slackware, or a BSD variant.
I would prefer something that is user-friendly for everyday use, but customisable. Gaming and programming friendliness also desirable.
#Linux #LinuxDistros #LinuxMigration
×xp -
Next Fest Feb 2025 Showcase Part 2
https://www.youtube.com/embed/00v4McbDXIAPart 2 of my (Josh Bycer's) favorite demos from the Steam Next Fest event.
0:00 Intro00:18 Gentoo Rescue1:37 Nitro Express2:43 Mother Machine4:01 The King
https://setsideb.com/next-fest-feb-2025-showcase-part-2/
#indies #Chromagun2 #DeckOfHaunts #DemonTides #GentooRescue #indie #indiegameshowcase #LastReport #MotherMachine #nextfest #Repose #SlidingHero #Squeakross #steam #TheKingIsWatching #TwilightMonk