Earlier quoted context omitted.
He was also a minor when the convicted offences took place. Important point because Lunduke acolytes always go everywhere & make it sound as if he was a grown man who molested children "thousands of times". Apparently what is closer to the facts is that he was himself a minor when he started SA his siblings, which was ignored by their parents. He was convicted later in life as an adult & as noted, served his time.
[flagged]
Debian 13 “Trixie”
411–420 of 428 posts
Re: Debian 13 “Trixie”
#412Re: Debian 13 “Trixie”
#413Re: Debian 13 “Trixie”
#414Re: Debian 13 “Trixie”
#415For those worrying about the NIC change with systemd, this comes from the release doc: https://www.debian.org/releases/trixie/release-notes/issues.... # example: udevadm test-builtin net_setup_link /sys/class/net/eno4 2>/dev/null ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link ID_NET_LINK_FILE_DROPINS= ID_NET_NAME=eno4 Here's a one-liner, excluding a bond interface and lo. Gives a nice list of pre and post…
Re: Debian 13 “Trixie”
#416Earlier quoted context omitted.
Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.
Oh thanks, I totally missed that distinctions. You’re right. My first thought is to wonder: why would systemd care about this then? Any idea? My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during b…
Re: Debian 13 “Trixie”
#417Earlier quoted context omitted.
Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos. I don't want to install an app that downloads and executes 500 node packages that I don't know what they do. Those packages should already be vetted and in Debian. If not, then I'm not interested. Side stepping the distro repos for dependencies for software in the repos leads to unexpected behavior.
> Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos. For a definition of cautious I don't personally share. Debian doesn't vet packages. Debian maintainers are less competent than the "upstream" they question approximately all the time, which is why they keep breaking stuff in more or less severe way (OpenSLL anyone?). And let's not even talk about the insan…
I can agree that debian maintainers are generally more incompetent, but they do actually vet dependencies for conforming to Debian ideology.
Upstream may be developing malware, they may be adding telemetry or ads. So if we just allow them to install 500 node packages that we don't know what they do... That's suspicious. That's asking for trouble.
Debian keeps a tight control on its supply chain. Its not perfect or bug free - but, it is within Debians goals.
So if you want a free distro with almost completely free sources, then Debian is really one of your only choices.
Re: Debian 13 “Trixie”
#418Earlier quoted context omitted.
I mean, that's just how OSS works. Anyone can fork your thing, do whatever, and call it a day. Going MIT or whatever won't save you either - this repackaging business is basically the entire business model of AWS.
Forking is fine, do whatever, but as soon as you make actual changes to the code then adopt your own name. This is what trademarks are for, it's just that official trademark registration is somewhat inaccessible (eg: cost) for open source projects. Could you imagine trademarking every little project you make just in-case it gets repackaged by someone who tears huge chunks of it out?
Re: Debian 13 “Trixie”
#419I can't believe we've come to such a high number, and a particularly lucky one at that Alas it's still not suitable as a daily driver for the average home user and probably never will be. It is unfortunate that Ubuntu has to reign supreme in that regard.
Re: Debian 13 “Trixie”
#420> i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. Impressive that i386 support made it all the way to A…
AFAICT this refers to Debian support, the Linux kernel does support 32bit CPUs though only since the original Pentium (excluding some clones).