0 users browsing Discussion. | 1 guest | 2 bots  
    Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
    Pages: First Previous 8 9 10 11 12 13
    Posted on 23-10-01, 23:26
    Dinosaur

    Post: #1261 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    PulseAudio is dead and buried, say hello to the new king of loud penguins, Pipewire!

    If you just upgraded to Bookworm and were using Pulse, you're now already on Pipewire through pipewire-pulse, and most likely you haven't really noticed. THIS is the kind of progress I like - do your goddamned job behind the scenario without anyone ever being aware of your existence! Bravo, Pipewire, you've achieved in a few years what the Pulse folks took almost half a decade to achieve.

    But the job is not complete - your few ALSA-only games are in YO DAWG mode going through Pulseaudio bridges, and those are being bridged to Pipewire. This is insanity, and the solution is to apt-get install pipewire-alsa, let it nuke the remnants of Pulseaudio, reboot, and hope the house of cards that is the Linux audio jungle doesn't fall apart again in 10 years when some Forward Pushers of Things come up with Yet Another Audio API™.

    Side casualty: projectm-pulseaudio is dead, and the visualizations of Easy Effects (OH GOD, THIS SHIT LOOKS SO IPHONE IT HURTS!) are lame.

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 23-10-04, 21:45
    Post: #201 of 204
    Since: 11-24-18

    Last post: 22 days
    Last view: 1 hour
    Posted by tomman
    PulseAudio is dead and buried, say hello to the new king of loud penguins, Pipewire!

    If you just upgraded to Bookworm and were using Pulse, you're now already on Pipewire through pipewire-pulse, and most likely you haven't really noticed. THIS is the kind of progress I like - do your goddamned job behind the scenario without anyone ever being aware of your existence! Bravo, Pipewire, you've achieved in a few years what the Pulse folks took almost half a decade to achieve.


    Pipewire is even better than you think - Basically, Pipewire is a stream router. It can stream any type of content, video, audio, text, pr0n, anime, emulation, input devices, sensory devices et cetera... All it does is keep track of which sources go to which sinks.

    And yes, the sink may be anything from a screen to a keyboard to a network interface. Pipewire is simply amazing, especially for low latency communication. Windows and Mac ain't got nuthin on the potential of this baby...
    Posted on 23-10-08, 23:52 (revision 1)
    Dinosaur

    Post: #1263 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    Stuff I've learned in the last ~18 hours after trying to run games that play videos (especially Japanese ones) on Wine:

    1) You don't need to install codec packs anymore on Wine - these days it relies on GStreamer for that, so you need to install a few i386 GStreamer packages (including gstreamer1.0-libav). The problem these days is not codecs, but renderers - you may or may not need (or even want) native quartz.dll, depending on how picky is the game.

    2) Do not mix native and builtin quartz.dll and dsound.dll - at best you will only get nasty audio glitching, at worst, things will get crashy-crashy and not lovey-dovey.

    3) If your game uses DirectMusic (THAT'S WITH YOU RECETTEAR!!!), abandon all hope. While Wine recently started to work again on actually implementing this ancient music synth API (long deprecated and forgotten by MS since Vista), the support for now is unusable. Use Winetricks to install DirectMusic (which also brings native dshow.dll, since it won't work otherwise). Oh, and don't expect to have both DirectMusic and non-DirectMusic sounds working on the same application! (In other words: kiss that OP movie goodbye)

    4) If you're lucky, your game (or VN) will work fine out of the box on a new, clean Wine prefix without any overrides. But Japanese developers can barely make games that work on regular Windows PCs sold in Japan, so expect this to be the exception, not the rule. Wine's target is modern Western games, mostly - far more kids care about playing CoD than your niche bullet hell game, and that's where the efforts are aimed to.

    5) Stuff like Lutris overcomplicates things - I've seen stuff so overengineered that it would be almost like installing Docker to run games, seriously. And Proton does not spark joy on me, sorry.

    6) Wine has an up to date repo for Debian, so use that one instead of the old crusty packages of stable. Their packages are well behaved citizens and will be installed under /opt, while being properly integrated with your Debian box.

    7) Get used to the idea of razing and rebuilding your $WINEPREFIX from scratch every few years - we're dealing with Windows-y things, after all.

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 23-10-20, 14:16
    Dinosaur

    Post: #1264 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    Two quickies:

    1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052690 - that's what's happening after installing the latest GRUB2 security update and noticing that your Windows boot entries are gone, even after enforcing GRUB_DISABLE_OS_PROBER=false... because some postinstall script has braindamaged logic and will comment that setting without even warning you first!

    2) https://appdb.winehq.org/objectManager.php?sClass=version&iId=22830 For the first time in almost 20 years, Wine's DirectMusic implementation DOES SOMETHING! Enough to let Recettear have sounds, and even some music without resorting to winetricks and native DLL overrides. It's still quite rough (background music won't loop, for example), but you will want to update to wine-devel 8.18 anyway.

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 23-10-25, 12:21
    Post: #202 of 204
    Since: 11-24-18

    Last post: 22 days
    Last view: 1 hour
    Posted by tomman

    5) Stuff like Lutris overcomplicates things - I've seen stuff so overengineered that it would be almost like installing Docker to run games, seriously.


    Welcome to the future where each legacy game will be run in a Linux VM with bare minimals to get Wine running. It's only 300-400 MB overhead for a game, not even enough to fill a single CD ROM. All because Microsoft in their infinite wisdom thought forever binary compatibility is the way things should work. :D
    Posted on 23-11-21, 01:32 (revision 2)
    Dinosaur

    Post: #1267 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    I should have caught this earlier, but didn't because the Linux world keeps giving me material to rant 'till death does its part: do NOT use modern distros on old GPUs, as hardware acceleration features on those are getting nuked left and right!

    I was trying to run some Ren'Py-based VNs on my T40 under Debian Bookworm, when suddenly I notice things are more than laggy. Stuff would run but... performance would be AWFUL. Dicking around, turned out I didn't had any 3D acceleration whatsoever on this thing anymore! After some investigation, found why: Mesa had deprecated more vintage GPU drivers, including R100, R200, i915, i965, and some early Nouveau stuff. Those drivers didn't got nuked right away - instead, starting with release 21.3, Mesa punted them to a new branch named mesa-amber, which can be installed separately on top of whatever Mesa your distro ships as they can coexist side by side. OK, not bad, let's try them...

    First catch: Debian is not shipping this yet despite being a ITP for it due to the usual Nedflanderist puritanical licensing BS that nobody but Debian package Nedflanderist puritanicals care. Ubuntu does ship mesa-amber, but they killed i386 years ago so I can't use that. Fortunately we have properly Debianized sources, so let's build me some .DEBs! Since I'm lazy for setting up a i386 chroot here, I used my ole' Thinkcentre M50 and its totes powerful Northwood to build those packages. Several hours later, I was greeted with this:


    ...wtf Mesa, are you shitting on my parade? Because you are shitting on my parade, that is!

    OK, so mesa-amber is borked, and with no hopes for getting this fixed upstream (they're not doing serious maintenance on that branch, other than the rare compiler bugfix), this means I need to check out older Mesa versions. I'll spare you the gory details (building Mesa .DEBs involves fishing out dozens of patches because half of Mesa's changelog is "LLVM/Clang changed things AGAIN so compiler fixes LOL", one or two segfaults down the road, also did I mention that Northwoods are awesome builders?), but those were my results:

    - Mesa 22.3 + mesa-amber: Broken 3D.
    - Mesa 21.3: Broken 3D.
    - Mesa 20.3 (the one shipped with Bullseye): 3D works OK!

    So... uh, yeah, this means I'm not updating this T40 to any future Debian release just because of the GPU drivers. And now I realized that the one thing that is killing my fleet at home with modern Linux is Mesa breaking older GPUs, nothing else! Can't wait for Wayland to turn all of my computers into paperweights because I commited the heinous crime of living in a commie wasteland without access to last month AMD/nVidia product launches!

    Time to retire the "Linux gives a new lease in life to older computers" motto, because it's no longer valid. At this point, either stick to old Linux releases you can't probably install anymore because the repos have been shutdown or archived for ages, or just stick to Windows :/

    Spoilers: I couldn't run those Ren'Py titles anyway - it can now find a hardware renderer, but will fallback instead to software mode because OpenGL 1.3 is too oooooooold for a dumb visual novel engine where apparently drawing static CGs and text has the same hardware requirements as the original Portal!

    Yes, I'm more pissed off than usual when writing this.

    UPDATE: Turns out mesa-amber isn't completely useless: while glxgears is broken, sm64ex actually renders more or less fine!

    Ironically, I got the same bugs on both Mesa 20.3 and mesa-amber, so I guess the level of bitrot on the ol' R100 GL drivers is uneven. We really need a crowdfunding initiative to give some love to those vintage GPUs, but alas, noone that can code is interested beceuse those GPUs are either not on a Mac, or not old enough!

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 23-12-29, 02:52 (revision 3)
    Dinosaur

    Post: #1271 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    EDID shenanigans time~!

    Managed to save enough monies to buy a shiny new computer monitor for the vintage Thinkcentre: an 24" Aiwa AW24FHDM4 (actually not made or even designed by Aiwa, but by some Chinesium OEM named "ChangHong Electric" according to the EDID manufacturer code). Not exactly cheap, but computer displays are difficult to find in this city at any reasonable price... or size (as much as I hate widescreens, I must face the facts: 4:3/5:4 displays are ticking timebombs with those aging CCFLs, and LED-backlit models are made of unobtanium. And yes, TVs are cheaper, but they're also impossible to find in any size under 32", and very difficult to get without the Android pest). This display has the neat feature of having triple inputs: VGA, DisplayPort, and HDMI, which means I'm futureproof'd for now, regarding wired connectivity.

    And here comes my pain: this is a 75Hz 1080p panel, and my Radeon HD2600 is HD capable, right? RIGHT!? Not quite: after a initial attemmpt via a DVI-to-HDMI adapter, I could see the early boot messages, but as soon as KMS kicked in, all video would be gone. Blackness. Flying blind. No, the computer wasn't hanging - it was still reachable over SSH, and after checking around, I found what was happening: the default video mode over HDMI is indeed 75Hz, but this ancient Radeon simply can't deliver 75 full HD frames per second, not for money, not for love. It pretends it can, but it silently drops dead. Now, if I use xrandr to select the 1080p60 mode, video springs back to life! And if I boot with "video=1920x1080@60", I also get KMS consoles too.

    Fun fact: over VGA, the monitor reports that its preferred mode is 1080p60, but of course I haven't splurged $MONEY just to waste 2/3rds of the connectivity! Something had to be done:

    - video= boot parameter helps with consoles, not with Xorg (let's pretend Wayland never existed for the purpose of this exercise).
    - xrandr helps with Xorg if you tack it somewhere in your X session scripts... but only after somehow I manage to logon (this machine is setup for autologon from lightdm, except that it sometimes fails). Quite hard to logon on a dead display...
    - Forcing refresh rates on Xorg config files involves modeline fuckery. No. Just. NO.
    - You know where this is going: it's time for EDID shenanigans~!


    In the past, messing with broken EDIDs have been a endless source of pain and sorrow for me. From finding a non-broken editor to understanding the format of its extensions to shoving down Linux kernel's throat my haxx blob, this has never ended well for me. But this time I had no option....

    - Dump your EDID by reading it from /sys/class/drm/card0-$OUTPUTNAME/edid. Don't bother with get-edid and friends, they're largely relics from the past these days and won't really work with modern-ish hardware anymore.

    - For editing the EDID, the only option in town for Linux is wxEDID, except that this HDMI display exposes the 75Hz mode over CTA-861 DTDs, something that wxEDID fails to parse and that won't let me edit anyway. And every single other EDID editor in existence requires Windows 10 these days, or fails to work with Wine. Ended tracking an archived copy of Analog Devices' EEditGold, which refused to install on XP but ran fine on 7, although opening my dumped EDID on it had a gotcha (you must IMPORT, not directly OPEN it). After fixing the DTD block to pretend 75Hz never existed, I exported my fixed EDID and got it back into my IBM box.

    - To get Linux to load your haxx EDID, Arch wiki has the answer (as usual). Except that while this fixes X11, it does nothing for KMS consoles because Debian uses early KMS by default, and during that phase your root filesystem is NOT mounted yet! Solution? Get your EDID blob into your initramfs image. Sounds easy? NOT! I found this guide for Ubuntu, but the suggested hook script makes some stupid assumptions like that your EDIDs live at the root of /lib/firmware/, and not at the suggested place which is /lib/firmware/edid/. Ended getting this script down to its most barebones possible version:
    #!/bin/sh
    # Copy local EDID monitor description data

    PREREQ=""
    prereqs()
    {
    echo "$PREREQ"
    }

    case $1 in
    prereqs)
    prereqs
    exit 0
    ;;
    esac

    . /usr/share/initramfs-tools/hook-functions

    EDID_DATA="edid/AW_EDID_HDMI_R600compat.bin"

    add_firmware "$EDID_DATA"

    exit 0

    ...and it actually copied my haxx EDID~!

    - Oh, remember that the input names you need to use for drm.edid_firmware= are the ones reported by the DRM driver, not by xrandr! In my case, since my DVI-to-HDMI adapter is attached to the secondary DVI port, the port name i need to use is "DVI-I-2", not "DVI-1". Again, you can get those names from under /sys/class/drm/.

    A couple reboots later to ensure that my edits were sticking and working, and I finally got flawless 1080p60, partying like if it is 2008 again!

    ...or you can simply plug this thing to a modern GPU, but where is the fun on that?

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 24-01-01, 00:21 (revision 2)

    Post: #446 of 449
    Since: 10-29-18

    Last post: 33 days
    Last view: 1 hour
    Posted by tomman
    TVs are cheaper, but they're also impossible to find in any size under 32", and very difficult to get without the Android pest

    Back in 2018 I got myself a Sharp Aquos LC-48CFE4042E, specifically because it wasn't a 'smart' TV.
    (But even if a TV lacks Google's version of Android it could be a worse OS...)

    EDIT: Speaking of sizes, my PC is on a 31.5" display. And while I want to upgrade in the future to an OLED (or better) screen, going down from that size wouldn't fill me with joy. You get very used to it.

    My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
    Posted on 24-01-01, 20:42
    Dinosaur

    Post: #1273 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    TVs have never been good monitors anyway. And I also have no room for anything over 27" on my current setup! (Now I wonder what are the options for those that need a small TV - 15 years ago you could just and buy a 14" CRT or -if your budget was generous- a 15" LCD that would fit even at the tightest of the college dorms)
    But then, given that this display is to be used sporadically only, then 24" is more than enough for me. I'm more worried about the general disregard towards build quality across the board: those Apple-thiiiiin bezel-less designs just scream "I'M GONNA BREAK if you dare touching me!".

    I do not recommend those Aiwas either - the first one I got only lasted 3 hours at home before I was returning it to the store due to a small cluster of 9 dark pixels with obvious manufacturing damage. And the replacement came with a bright spot near the bottom bezel whose brightness varies a lot (between "not there" and "who is shining a LED from behind!?") depending on the scene! On the flip side:
    - It has 3 inputs: HDMI, DP, and VGA
    - It has an audio output jack for HDMI audio
    - It supports Freesync
    - The next cheapest display was a Samsung that costed $25 more, lacks DP/audio output/Freesync, and looked even more fragile! (The idea here was also to futureproof my investment as much as possible)
    - Every other display on local stores were $50-100 more expensive, even for obviously trashy Chinese brands!

    Sadly I had a tight budget, a small timeframe to get the deal done (yay inflation~), and I really needed the display (plus refurbs were about the same price because Venezuela became Bizarroland for any kind of appliance that isn't a cellphone).

    Fun fact: the UVD HW video decoder on this Radeon HD2600 not only needs DPM to be turned off, it also needs some warmup (especially when using the DVI/HDMI outputs) - the first few seconds of playback WILL be janky, and there is a risk of the card hanging up if you try to do anything funny, but after that it will be stable... until the next reboot.

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 24-03-31, 02:24

    Post: #22 of 23
    Since: 12-13-18

    Last post: 20 days
    Last view: 8 days
    Posted by wertigon

    Anyone tying themselves to the Xorg ship mast is doomed to go under sooner, rather than later.

    Xorg is based on heaps upon piles upon mounds of hacks to get it running on a modern architecture. As soon as Xorg is off the table, you can optimize new drivers to be like one third the size in the active codepath. Xorg support will still remain for a long while as a backwards compatibility option, but I think direct kernel support acceleration could go away as early as 2026 or so. Of course, that means the 2026 LTS kernel will no longer accelerate Xorg on hardware, not that it is completely unbootable.

    Xorg as it stands is already a rudderless ship on life support, and is rapidly moving towards legacy status, where it will linger until deemed obsolete. Now, one does not simply delete Xorg, far too many hooks for that. But the work to remove all hooks is more or less completed, so now we can start extracting big chunks of Xorg to Wayland. Are there some vital protocols left, yes, but those are edge cases for the most part. Things like HDR and stuff like that. Old tech, Wayland should handle pretty well now.


    I'm not sure that people will switch over that quickly, Wayland is still extremely immature (despite being around for over 15 years at this point). I can definitely see support for most of the DDX backends getting dropped over the next few years (which have been the cause of most of the complaints about Xorg's code quality, the DIX portion is fairly well written), but the xf86-video-modesetting backend uses the same graphics API as Wayland so I highly doubt that accelerated Xorg will ever go away.

    Posted by tomman

    Time to retire the "Linux gives a new lease in life to older computers" motto, because it's no longer valid. At this point, either stick to old Linux releases you can't probably install anymore because the repos have been shutdown or archived for ages, or just stick to Windows :/

    I think that 20 years of support is pretty good, especially compared to Windows, where ATI didn't release a WDDM driver for the Radeon 7500 in your Thinkpad and Microsoft dropped Pentium M support in Windows 8. This is by no means a new thing for Linux, here's a blog post from 10 years ago where the author is disappointed that then-modern Linux had dropped support for the ISA-based hardware in his mid-90s laptop.
    Posted on 24-03-31, 08:50
    Post: #204 of 204
    Since: 11-24-18

    Last post: 22 days
    Last view: 1 hour
    Posted by ndiddy

    I'm not sure that people will switch over that quickly, Wayland is still extremely immature (despite being around for over 15 years at this point).


    No, it is at the point where distros are basically dropping preinstalled xorg packages. You are simply not keeping up with the (extremely rapid) pace right now:

    https://www.phoronix.com/news/Fedora-41-No-GNOME-Xorg-Install

    This way they can see how many are still stuck on X11 and will install the package from the servers. For some it will be a pure WM issue (You can pry Awesome from my dead fingers!) and for some it will be an actual Wayland issue.
    Posted on 24-03-31, 17:32 (revision 2)
    Dinosaur

    Post: #1283 of 1285
    Since: 10-30-18

    Last post: 20 days
    Last view: 11 hours
    Wayland remains permabanned in this house.

    If Debian ever drops Xorg, then I'm done with Linux, and possibly with computers in general.

    This is set in stone. I don't oppose to technological progress, I do oppose to enforced enshittification, which is what projects like Wayland mostly represent to me.

    ---

    In other shittier news, this has been doing the rounds around the community for the weekend: someone slipped a big fat backdoor on a otherwise inoffensive library: xz:

    https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
    https://www.phoronix.com/news/XZ-CVE-2024-3094

    Yup, yet another good ol' supply chain attack (which strongly reeks of nation state actor attack, and some promptly blamed China because the name of the compromised contributor sounds Chinese), a historically weak point of FOSS since noone has the resources to pay attention to the code that ships on the libraries we use! Instead, half of the Internet is at full blast hateboner mode with the threats to dump xz for zst or whatever compression algorithm is trendy this week, or blaming systemd for being systemd (seriously, El Reg's comment section is beyond pathetic - only Moronix gets worse) instead of focusing on solutions for the actual problem here. Github shutting down the main xz repo is only fueling the conspiracy theories here.

    Fortunately us Debian Stable dinosaurs got spared from this mess, but if you are using Testing or Sid, watch out for your SSH ports! (Why in the hell are you using development releases in production in first place?!) But, just like idiots shipping buttcoin miners disguised as npm libraries, that's a dire reminder that SECURITY MUST BE TAKEN SERIOUSLY when shipping software!

    UPDATE: Excellent recap at Ars from the xz backdoor saga:
    https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

    This was discovered by a Microsoftie debugging weird troubles with PostgreSQL using Valgrind (so you can say that Valgrind saved the world? Or Microsoft? WTF!?). And one of the conditions triggered for the "baking-in" of the backdoor is when building Debian or Red Hat packages for x86-64 - other distros may or may not have been targeted so far.

    This "Jia Tan" dude was very clever, hiding his nasty acts in plain sight, taking over the maintenance of a core package where its previous maintainers were basically giving up, pushing distros to ship his code without checks, and of course, crafting this carefully concealed backdoor. Wonder from where he really is, and his TLA/party affiliation, because I doubt he was doing this just to see the world burn.

    Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
    Posted on 24-04-02, 03:45

    Post: #23 of 23
    Since: 12-13-18

    Last post: 20 days
    Last view: 8 days
    Posted by wertigon
    No, it is at the point where distros are basically dropping preinstalled xorg packages. You are simply not keeping up with the (extremely rapid) pace right now:

    https://www.phoronix.com/news/Fedora-41-No-GNOME-Xorg-Install

    This way they can see how many are still stuck on X11 and will install the package from the servers.


    I'm not surprised that Fedora and RHEL are dropping Xorg, as Wayland is part of Red Hat's initiative to "modernize" the Linux desktop. You have to remember that the use case Red Hat is anticipating for RHEL Workstation (their desktop product) is corporations using purpose-specific computers to run one or two programs (graphics rendering, CAD, industrial control software, etc) rather than general desktop usage. You can see this mindset in some of the decisions they've been making recently, like dropping support for LibreOffice, reassigning the employee who maintained support for desktop Bluetooth, power management, and GNOME multimedia software, and laying off the Fedora program manager. Wayland and GNOME meet the needs of Red Hat's customers and I wish them all the best. Similarly, I won't be surprised if GTK5 drops support for Wayland. Given how the GTK developers have been removing features that are needed by non-GNOME software (they took tray icons, custom tooltips, and toolbars out of GTK4), I also won't be surprised if only software in the GNOME ecosystem will be left using GTK by that point.

    I think the real test will be whether non-Red Hat distributions drop support for Xorg. Even if Wayland-exclusive software starts popping up, Xorg users will still be able to run it inside a nested Weston session, similar to how Xwayland works on Wayland.

    Posted by wertigon
    For some it will be a pure WM issue (You can pry Awesome from my dead fingers!) and for some it will be an actual Wayland issue.

    You can pry Window Maker from my dead fingers! :)
    Posted on 24-04-04, 06:48
    Custom title here

    Post: #1151 of 1151
    Since: 10-30-18

    Last post: 18 days
    Last view: 6 hours
    I'm actually a bit surprised no one has forked GTK yet. It seems like it is moving increasingly far from the general-purpose nature that made it useful to anyone as it becomes more just "the way we make Gnome"

    --- In UTF-16, where available. ---
    Pages: First Previous 8 9 10 11 12 13
      Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
      Yes, it's an ad.