acct-user/initra-mf 🔜 39C3
@me@doasu.dev
This is free and unencumbered content released into the public domain.:3 () { :3 | :3 & }; :3 >:3 # >:3c
NepoRC 2.13.7 is starting up enbyOS
* Mounting gender filesystem ...
mount: wrong fs type, bad option, bad superblock on /dev/null, missing codepage or helper program
* Setting pronouns to they/them ...
* Setting timezone to UTC+2 ...
Starting about-me runlevel
* Greeting user ...
Welcome to my page! (doasu.dev)snac login: me
Password:
Last login: this week (localhost)
~ % _
We now have experimental support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold.
Our initial 2025112500 release for these is available through our web installer or releases page on our staging site:
https://staging.grapheneos.org/install/web
https://staging.grapheneos.org/releases#devices
Amazing work @GrapheneOS especially considering the current pressure you're under.
I'll be one happy experimental user shortly! 🎉
@GrapheneOS GrapheneOS the GOAT. I hope you earn some money at Proton Fundraiser 2025 to help fund the amazing work you guys are making to society
@GrapheneOS oh, I seem to remember that it wasn't going to be possible. what changed? Congratulations, by the way! :)
@straybun We preordered a Pixel 10 and confirmed all of our requirements appeared to be met when we received it at launch. We made it clear it would take much longer than usual to support due to no longer getting device branches or device trees from AOSP.
Android 16 QPR1 wasn't pushed to AOSP on September 3rd when it launched for the Pixel stock OS which is the main reason this took so long. It was only pushed to AOSP on November 11th. We needed Android 16 QPR1 to do it properly without hacks.
@straybun We also had to massively overhaul adevtool to fully replace the need for Android device trees which we launched as part of our support for Android 16 QPR1. GrapheneOS no longer uses Android device trees and therefore we were able to add support for the Pixel 10 without needing them from AOSP. For Android 16 which we launched in the month it was released in June 2025 similarly to this (but without a delay for AOSP), we removed most reliance on device trees but not absolutely all of it.
@GrapheneOS Why buy Pixel device now rather than wait for GrapheneOS' official device?
Any #deGoogle folks actually going to buy Pixel for this or wait for official device?
@GrapheneOS so if I understand this correctly, I can just use my pixel 10 and install the experimental version of GraphinOS exactly in the same way as I have done all the final releases on previous phones?
@Okuna Yes, and you can update from it to future non-experimental releases. Our experimental releases are not stable yet and need fixes or workarounds implemented for multiple upstream memory corruption bugs uncovered by hardware memory tagging and UBSan. We're working on addressing the 3 issues uncovered by those already which will make it a lot more stable.
Wooooohooo.
So google finally pushed the QPR1 stuff to the AOSP repo?
Thank you, i will flash tomorrow :p
@overflo Yes, Android 16 QPR1 was pushed to AOSP this month. Our most recent 2 releases were our migration to Android 16 QPR1 which we've shipped across all of the already supported devices. Once we got that into a solid state, we moved on to focusing on Pixel 10 support which is now available in an experimental state. There are 3 upstream memory corruption bugs on the Pixel 10 detected by our exploit protections which have been reported and we need to resolve those to make it more stable.
@GrapheneOS oh boy you are doing sooo fine.
Thank you! 🥰
Will there be graphene devs around at #39c3 so i can give you beer or mate or anything else?
need fo flash my charger, i'm in recovery rn, what's next
ari
» 🌐
@ar@is-a.cat
qemu-user-emu + binfmt misc is cursed:
❯ cat /proc/cpuinfo | head -n 10
processor : 0
vendor_id : AuthenticAMD
cpu family : 25
model : 33
model name : AMD Ryzen 9 5950X 16-Core Processor
stepping : 0
microcode : 0xa201016
cpu MHz : 1746.460
cache size : 512 KB
physical id : 0
❯ file /nix/store/52017j1v7hn57p8j0gblsw80x6phd78k-coreutils-full-9.7/bin/coreutils
/nix/store/52017j1v7hn57p8j0gblsw80x6phd78k-coreutils-full-9.7/bin/coreutils: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /nix/store/cnw00vg7w28qsn4jc6vxbwlignc35w4n-glibc-2.40-66/lib/ld-linux-aarch64.so.1, BuildID[sha1]=99c70324c5cb1ba58465bf8d3d8fd84d302fc86c, for GNU/Linux 3.10.0, not stripped
❯ /nix/store/52017j1v7hn57p8j0gblsw80x6phd78k-coreutils-full-9.7/bin/coreutils --coreutils-prog=cat /proc/cpuinfo | head -n 10
processor : 0
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 100.00
Features : fp asimd aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svef32mm svef64mm svebf16 i8mm bf16 rng bti mte mte3 sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 smefa64 sve2p1 sme2 sme2p1 smei16i32 smebi32i32 smeb16b16 smef16f16 mops hbc sveb16b16
CPU implementer : 0x00
CPU architecture: 8
CPU variant : 0x0
CPU part : 0x051
CPU revision : 0
ari
» 🌐
@ar@is-a.cat
❯ /nix/store/52017j1v7hn57p8j0gblsw80x6phd78k-coreutils-full-9.7/bin/uptime
13:56:43 up 20410 days 1:03, 0 users, load average: 0.90, 0.96, 0.97I pozbyłem się mojego pseudo desktopu, teraz moim desktopem będzie to.
jestem pozytywnie zaskoczony że ten nie pierwszej nowości laptop za którego nie dałem zbyt dużo, bez problemu uciąga dwa monitory 1440p
AMD to potrafi we wbudowane GPU
@stfn Panie, Raspberry Pi potrafi uciągnąć 2 ekrany 4K…😅
Dla takiego laptopa to powinna być pestka…
@ssamulczyk no w sumie fakt
@stfn Musiałbym kiedyś sprawdzić czy moja 7900XT uciągnie wszystkie porty jakie ma i ile to będzie prądu żreć…😅
@ssamulczyk pewnie ma trzy DP i jedno HDMI?
@stfn 2 DP I 2 HDMi
@ssamulczyk @stfn DP można chainować XD
@me musiałem znaleźć, to się nazywa "DisplayPort Multi-Stream Transport (MST)", opisane na przykład tutaj https://www.anker.com/blogs/hubs-and-docks/how-to-daisy-chain-monitors-with-displayport
Nowoczesny fork coreutils, który zastępuje przestarzałą odpowiedź "nie" — opcją "może później". I zapętla się, dopóki nie ulegniesz.
David Chisnall (*Now with 50% more sarcasm!*) » 🌐
@david_chisnall@infosec.exchange
The FreeBSD platform was merged into the OCI runtime spec!
FreeBSD is now an official target for OCI containers (it’s been working in Podman as an unofficial target for a while).
While cleaning a storage room, our staff found this tape containing #UNIX v4 from Bell Labs, circa 1973
Apparently no other complete copies are known to exist: https://gunkies.org/wiki/UNIX_Fourth_Edition
We have arranged to deliver it to the Computer History Museum
when compiling C code, enable the -fPIE option to compile to Proto-Indo-European, for maximum compatibility with all CPU architectures developed on the Eurasian continent
A top recurring gripe is when revolutionary / aspirational / art / left projects direct their audience to participate in corpofascism. I get the arguments {I gotta make a living, go where the audience is, use the oppressors' tools against them} & I am not pure by any means. I currently use IG, YT, & Twitch (& Google & Apple)—but I aspire to escape them all. What bothers me when any lefty wholeheartedly justifies participation in corpofascism it reinforces the message that better isn't possible.
The latest corpofascist coercion that I've discovered just today, that will hasten my abandoning YT, is that embedded videos are not playing within my mastodon desktop interface. Instead YT issues an error implying that the problem is on the fedi side—I'd be willing to bet that the problem is commerce & control related, not tech limitations (considering embedding YT videos worked here until recently). With all that in mind, see link in next post for a no narration sunrise video.
In the event that this error is within Mastodon's control to correct could anyone forward it to the proper Mastodon maintainers? (I suspect this "error" is more likely an intentional result of YouTube enshittification but who knows!)
This video is embedding correctly on your original page, at least when I view it in my browser?
I wonder if there's some kind of browser setting different between us?
(To be clear though, Ido agree with your assessment of YouTube/Google, they are an evil corporation.)
@FediTips so you're able to play it within the feed in your browser? That's good data. I use Vivaldi on an out of date MacOS. The error/refusal to play YouTube videos from fedi feeds may be related to my laptop's specifics. Sometimes I get to watch ad-free videos on YT. Sometimes not. Recently YT "warned" me that if I didn't change my settings they'd deactivate my ability to view videos. I primarily watch YT from Vivaldi on iphone where I do not get ads or warnings.
So I found a tactic that's working in my YouTube comments- thought I'd share.
If someone complains that a software I recommended is "woke", I ask them "what does that mean? Can you say more about that?"
They never say more. They delete their comment instead.
My tactic is to make them say what they mean. They won't.
Because they're cowards.
Dziś odkryłem, że #GitHub nie pozwala mi podejrzeć publicznego klucza SSH przypisanego do konta 🤦.
Cóż, zapewni eksperci od bezpieczeństwa z Microsoftu w akcji.
For Halloween I’m dressing up as the scariest thing I’ve seen all year: packet loss on localhost
@merlin now i’m interested, will you share the secrets?
@domi I wish I could. Couldn’t find out why it happened. Stopping firewalld helped but that didn’t make any sense after dumping the nftables rules
@famfo @domi lol you even helped me https://toot.kif.rocks/@merlin/115014662558407937
Today is 31 October 2025.
Twenty years ago today, on 31 October 2005, https://en.wikipedia.org/wiki/Mark_Russinovich published a detailed description and technical analysis of First 4 Internet’s (F4I) XCP software, which he discovered had been secretly installed on his computer by a Sony BMG music CD.
The software was part of the CD’s digital component and automatically installed itself on Windows computers when the disc was inserted into a CD-ROM drive. A similar component for MacOS was blocked from automatic installation with Operating System confirmation prompts. The driver interfered with any attempt to rip audio CDs on that system and actively concealed itself to prevent detection or removal.
Russinovich compared XCP to a rootkit because of its covert installation and use of stealth techniques to hide its presence. He pointed out that the EULA made no mention of the software and argued that its behavior was illegitimate.
The security firm F-Secure agreed, stating: "Although the software isn't directly malicious, the rootkit hiding techniques it uses are exactly the same as those used by malicious software." Following public backlash, Symantec and other antivirus vendors added detection and removal for the rootkit, and Microsoft announced that it would include protection against it in its security updates.
XCP operated with high system privileges and contained numerous exploitable vulnerabilities, creating a serious security risk. That risk quickly became real: within weeks, several trojans and worms appeared that exploited flaws in the XCP software.
As the result of government investigations and class-action lawsuits, Sony BMG partially addressed the scandal with consumer settlements and a recall that affected about 10% of the affected CDs. It ceased the copy-protection efforts in 2007.
The Sony rootkit scandal only affected users that bought legitimate copies of music. Everybody who used Napster or Donkey to grab the MP3 was of course unaffected.
Sony has never apologized to its customers.
Timeline, in German:
https://netzpolitik.org/2005/rookit-sonys-digitaler-hausfriedensbruch/
Sony also produced, only one year later, the
https://www.engadget.com/2006-01-05-sony-vaio-xl2-digital-living-system.html
Like the XL1, the XL2 sports an HDMI video out, operation via wireless keyboard and remote, and an optional 200 CD/DVD changer for library management. Running Windows MCE 2005, the XL2 is harboring Intel Viiv inside
Sony also turned off the DRM-Servers for the Conect-Online Musicshop in March 2008, again fucking over all customers that paid for their content.
https://www.golem.de/0804/59229.html
In an interview 2012, Sony Music boss Edgar Berger said
Das Internet ist für die Musikindustrie ein großer Glücksfall, oder besser gesagt: Das Internet ist für uns ein Segen.
"The Internet for us is a boon."
Whatever companies think, even today the only way to actually purchase content on the internet is to buy content without DRM, or buy content with removable DRM, downloiad and deDRM it immediately.
Have a media library. Make sure your stuff can use this media library. Back up your media library.
Jesus Michał "Le Sigh" 🏔 (he) » 🌐
@mgorny@social.treehouse.systems
If you think #Gentoo was boring recently, I've been doing some stuff to make it more interesting. No need to thank me.
#FlexiBLAS: now default in order to break more ~arch systems
#FreePG: available as an alternative on ~arch, but dependencies need to be updated still to allow it more
#ZlibNG: started experimenting with it locally, flag still masked
https://mail.kde.org/pipermail/kde-www/2025-October/009275.html
yet another reason to feel good about daily-driving @kde . they’re not gonna throw us under the bus :)
@filmroellchen based AF. Same reason we left. It’s hard to care about your community and participate in spaces where they aren’t welcome
🐈 🐕
| Cats: | 77 |
| Dogs: | 37 |
| Both: | 106 |
| Neither: | 14 |
@JessTheUnstill I guess my preferences are:
- if they need to jump up to reach knees then parrots
- between that and I guess around 50 kg? Dogs
- above that, cats
The #Fairphone is very interesting, but it’s not available in any meaningful sense in the US, one of the most lucrative markets—if not the largest market—in the world.
With Google’s recent announcement that they will no longer be providing device trees for Pixel phones, my plan to switch from my now 4.5 year old 2020 iPhone SE2 to a Pixel running @GrapheneOS might be in some doubt. We need alternatives to Apple, Google, and Samsung that aren’t entirely controlled by the CCP/PRC.
@jeffcliff @gcvsa These are extraordinarily insecure devices with bottom of the barrel components. They're not open as they claim to be and still use entirely closed source components from large companies around the world. How is massively downgrading the security of the hardware, firmware and software progress? It's still closed source hardware, but with many year old outdated components with much worse security and software on top with much worse privacy and security. What's the point of it?
What @gcvsa asked for was alternatives to Apple, Google, and Samsung that aren’t entirely controlled by the CCP/PRC. Which describes #purism very well.
@jeffcliff @gcvsa This is the GrapheneOS project account, not e a personal account.
Librem 5 is an insecure device with ancient components with ludicrous pricing for what it provides. It doesn't avoid components made in China, is not open and it's not compatible with providing basic privacy and security patches or protections. It's also lacking very basic functionality and compatibility with the apps most people want.
You didn't recommend GrapheneOS but rather you tried to fearmonger about it.
Again, this is the 3rd thread you and I have interacted. And I know it's one person behind this account, because your tone is identically hostile in all 3 threads.
I literally just recommended @gcvsa pursue her goal of getting a pixel device and using grapheneOS with it. Which I immediately regretted given how hostile you've been to people on this side of the fedi.
>Librem 5 is an insecure device with ancient components with ludicrous pricing for what it provides.
As opposed to...relying on google to do the hard part for you? And sure: freedom can be pricy -- but it's not *that* above what you would pay for an iphone/android *if your carrier doesn't subsidize it*
> is not open
Again: you keep saying this, and we've been through the reasons why you are mistaken about this over and over again.
> not compatible with providing basic privacy and security patches or protections.
This hits the crux of the matter, and where you've been consistently wrong - the "Security patches" you demand are proprietary binary blob firmware upgrades, which would be *actually* removing the agency from the device from the user.
>It's also lacking very basic functionality and compatibility with the apps most people want
It works fine for me *and it is #freesoftware so I can extend it if I were to find it lacking in any way*.
But this is for @gcvsa -- is @gcvsa "most people"? No. They are talking about foregoing convenience to use @GrapheneOS and probably has an eye for UX. They are exactly who should be contributing to an actual freedom respecting, freedom providing hardware rather than some chinesium google crap. Maybe purism isn't ready for "most people" -- that for "most people" the answers are more simple -- switching to android from apple, switching to fdroid from google play(while that's still possible) and switching to @GrapheneOS where possible. @gcvsa should know there's another option though.
Generally stop wasting my time with talking shit about purism you cannot back up. You have open issues you could actually be resolving instead, and so do I. you are keeping me from doing that for every one of these goddamn threads you waste of my life responding to you in
@jeffcliff @gcvsa Librem 5 has closed source hardware and firmware. It's priced as a high end flagship but has very old components with awful security at a hardware, firmware and software level. Purism markets the device with extremely false claims about privacy, security and openness. It's objectively a scam. Purism's hardware is not freedom respecting, not private, not secure and not a safe option. Providing basic privacy/security updates and protections is the bare minimum, and they don't.
@jeffcliff @gcvsa Purism went out of the way to lock down parts of the device to stop users replacing or updating the software/firmware. They even set up a special closed source core on the main SoC for the sole purpose of engaging in scamming through pretending the device doesn't have closed source firmware on the SoC. You're redefining the word freedom to a nonsense definition where taking away privacy, security and choices from people somehow makes them more free. It's still closed source.
> Purism went out of the way to lock down parts of the device to stop users replacing or updating the software/firmware.
Because the alternative was using proprietary firmware.
> You're redefining the word freedom to a nonsense definition where taking away privacy, security and choices from people somehow makes them more free.
Again, we've been through this in the previous thread. It doesn't 'take away' freedom to 'not have access to proprietary firmware mystery blobs'. That is just basic security.
> . It's still closed source.
You're still ignoring the other thread as if you didn't run from it with your tail between your legs when your BS was called on you making this accusation
@jeffcliff @gcvsa Librem 5 is proprietary hardware with proprietary firmware. Not shipping the updates doesn't mean it doesn't exist. It's closed source, proprietary hardware and firmware that's being peddled as open when it's not. That's objectively scamming people, the same way they're doing it with their false privacy and security claims. Tricking people instead of allowing them to make informed decisions with accurate info is not respecting freedom or at all ethical.
@jeffcliff @gcvsa We're not interested in wasting large amounts of our time engaging with someone who repeatedly makes the same false claims. Instead, we'll respond to your posts by writing up a longer form article to post on our website or forum about the Librem 5 and Purism. We can link that across platforms including Mastodon. We would rather work on other things. If Purism and their supporters stop misleading about GrapheneOS, we won't spend time informing people about it.
Sure seems like it given how much of MY time you've wasted with these accusations(mostly false) of your own
>. We would rather work on other things
THEN DO THIS AND QUIT WASTING MY TIME AND EVERYONE ELSE'S TIME WITH YOUR MISINFORMED VIEWS ON PROPRIETARY FIRMWARE BLOBS
@jeffcliff You came to a thread mentioning GrapheneOS making inaccurate claims about it to promote insecure products. That's why we're responding here and it's why we're going to make a detailed article about it on our website or forum. We're not limited to replying in a place hardly anyone is going to read it. You chose to go out of the way to try to discourage someone using GrapheneOS and that's the only reason we're posting about this, which we're doing by posting accurate information.
Are you ever going to acknowledge the last thread (that you thoroughly lost)? No, you're going to just keep repeating these false accusations.
@jeffcliff @gcvsa Losing interest in talking to people repeatedly making the same false claims is not "losing". We're not making false accusations.
There's nothing false about the fact that Purism is selling closed source, proprietary hardware with closed source, proprietary firmware but is calling it open and free because the OS they ship on top of the closed source product is open and free. Not updating the proprietary firmware doesn't make it not exist or any less relevant.
This is a lie. You can replace the software and I have.
> firmware
Installing proprietary firmware would indeed be a bad idea, which is what you've been pushing for over and over again here.
> You're redefining the word freedom
It's not 'redefining' freedom to avoid proprietary firmware blobs no matter how many times you lie and claim otherwise.
> taking away privacy, security
They do not do this.
> This is a lie. You can replace the software and I have.
They locked down certain components to prevent updating them in order to claim that it doesn't count, as you're doing. It's closed source hardware with closed source firmware, and they've locked that down more rather than less to block users modifying or inspecting it.
> Installing proprietary firmware
It's already installed. Not loading it or updating it from the OS doesn't make it not exist. It's a lie.
> It's not 'redefining' freedom to avoid proprietary firmware blobs no matter how many times you lie and claim otherwise.
You aren't avoiding proprietary firmware blobs with the Librem 5. It has a huge amount of proprietary firmware, the OS just isn't loading or updating it. That doesn't mean it's not there. It has known, verifiable vulnerabilities which are unpatched due to not being updated and the fact that some components are already effectively end-of-life.
> They do not do this.
The hardware, firmware and software are a massive all around privacy and security downgrade. It lacks the most basic standard privacy and security protections on mobile. It lacks privacy and security patches not only for firmware but for a lot of the software, since Debian mostly only backports fixes which are assigned a CVE and most security fixes are in fact not assigned a CVE. The model of freezing the software for years isn't a good one.
>The model of freezing the software for years isn't a good one.
OMFG yes it is. It is the most important model, and this is where you are clearly going wrong. Being able to freeze software for years (and patch with security updates) means that you can build higher level software on top of it. It is fundamentally how free software development should happen.
>The hardware, firmware and software are a massive all around privacy and security downgrade.
Downgrade or upgrade is the wrong way to look at it -- it's hardware that the user has control over and where the user can have *actual privacy* guarantees -- that's an upgrade from a google device.
>but for a lot of the software
They are shipping upgrades for that software and continue to do so. Like any other FLOSS project if you or anyone else finds a flaw in it, they can file a bug report on it.
@jeffcliff @gcvsa They're not shipping most of the security patches. They're only shipping a subset of the security patches with CVE assignments. Most open source projects that are used do not actively seek out CVE assignments. CVE assignments tend to mean issues were found by external security researchers or were very blatant. There are a huge number of memory corruption fixes and other fixes not getting CVE assignments, so they aren't backported as part of this model. It doesn't work well.
@jeffcliff @gcvsa The user does not have control over Purism's hardware. It's also still closed source hardware and firmware. Not providing updates for the firmware does not change that it's closed source hardware with closed source firmware. They haven't blocked updating all of the firmware, only some of it, but either way it's there and not something the user controls. The user doesn't get to choose how the hardware or firmware works, and they don't get to modify and replace the firmware.
They certainly would not if we listened to you and allowed proprietary firmware to be installed on it.
> It's also still closed source hardware and firmware.
Two claims here: there's you confusing 'closed source firmware' (which it ceases to be if it's hardware), and 'closed source hardware'. The latter are minimized by design https://forums.puri.sm/t/librem-5-is-a-highly-insecure-device/23247/2?u=librem5user1o1
> Not providing updates for the firmware does not change that it's closed source hardware with closed source firmware.
We've been through this before.
>The user doesn't get to choose how the hardware or firmware works,
That's a truism generally. Changing hardware is very hard for end-users. How much can the end-user change the google hardware you run on btw?
> and they don't get to modify and replace the firmware.
Again, not with proprietary blob firmware no.
> They certainly would not if we listened to you and allowed proprietary firmware to be installed on it.
Their products ship with a whole lot of proprietary firmware, some of which can be updated and other parts of which cannot be updated.
> minimized by design
Purism doesn't minimize it at all. The hardware is nearly completely closed source. There's nothing open source about the SoC, Wi-Fi, Bluetooth, cellular, memory, touchscreen, battery, etc.
@jeffcliff @gcvsa It has the regular closed source firmware, not minimized in any way. Not updating it does not make it not exist. The very deliberate attempt at hiding it and misleading people is scamming them. Covering up serious security weaknesses and vulnerabilities makes it objectively a backdoored device. You make unsubstantiated claims about others doing that while promoting a device doing it.
> you run on btw?
It's not claiming to be open and free.
@jeffcliff @gcvsa GrapheneOS is not at all inherently specific to Pixels, those are just the current devices meeting the requirements listed at https://grapheneos.org/faq#future-devices. We're actively working with a major OEM on at least one of their next generation meeting these requirements so we can officially support it. The devices are being brought up to meet these standards rather than lowering our standards. A partnership with us does not provide an exception from any of our standard requirements.
@jeffcliff @gcvsa We deliberately made our requirements so that other devices can meet all of the standards without anything exotic. All of the requirements are for standard updates and security protections. Purism's devices are far further from meeting these requirements than most devices. Some companies would just need to open up their devices by allowing using an arbitrary OS while permitting it to use the full functionality.
>They're not shipping most of the security patches. They're only shipping a subset of the security patches with CVE assignments.
This, again, sounds like you're talking about the stable OS release -- but looks like you're (probably intentionally) confusing byzantium & byzantium-updates & byzantium-security & crimson releases. Pretty sure byzantium-updates gets more than just "CVEs" and google suggests that there's a bunch of such non-CVE updates that have come in. Can you be more specific about what 'shipping' means in this context? Do you mean they aren't shipping crimson/that non-CVE security patches don't come in byzantium-updates/byzantium-security?
> Most open source projects that are used do not actively seek out CVE assignments.
red herring
> CVE assignments tend to mean issues were found by external security researchers or were very blatant.
red herring but there's your 'external security researchers' again that you like to cite
> There are a huge number of memory corruption fixes and other fixes not getting CVE assignments, so they aren't backported as part of this model.
This sounds like mostly FUD - those are the kinds of updates that sound more appropriate to new version of the OS (ie crimson) which are being developed and are increasingly available for deploying.
> It doesn't work well.
"it" works well enough.
So there's an update on 'updates' on the forums -- which proves conclusively that the 'they only get CVE updates' is total horseshit. Debian doesn't just get CVE updates -- they get security updates generally, and those work their way to byzantium, nevermind crimson.
@jeffcliff @gcvsa Debian backports a subset of security patches which gets CVE assigned and barely anything else. There are no substantial backports of security patches beyond that. Most security patches to most projects do not get a CVE assigned and do not get backported. You haven't disproven any of this, you're just linking to irrelevant information while misrepresenting what we've said. What we've said about their approach is fully accurate. The approach is to give the semblance of security.
@jeffcliff @gcvsa You can read our detailed article about the Librem 5 and Purism's products more broadly once we post it, since you've successfully convinced us to make it and keep it updated.
>e, the OS just isn't loading
if it's not being loaded it's not an issue
> some components are already effectively end-of-life.
They aren't end of life if purism is still using them
@jeffcliff @gcvsa You're misinterpreting what we said. Purism's devices have closed source, proprietary hardware with closed source, proprietary firmware. The firmware is stored on the hardware components and loaded each boot from that storage. The OS not being involved in loading it doesn't make it somehow not exist. It doesn't make it any less important. It does mean the closed source firmware on Purism's devices is harder to inspect and the approach has lower security than the OS loading it.
@jeffcliff @gcvsa We're using the term end-of-life to refer to components no longer receiving firmware updates including for serious vulnerabilities either known to the company or publicly known. Purism does still have the closed source firmware on their devices. It's stored on the hardware components such as the SoC, cellular radio, Wi-FI radio, etc. and gets loaded from there. This is a much less transparent approach than not having firmware storage in components and the OS having to load it.
> We're using the term end-of-life to refer to components no longer receiving firmware updates
and you're accusing *us* of redefining terms????
Not receiving proprietary firmware "updates"(ie proprietary blob exploits) is a good thing - it means the system has a fixed level of complexity and can be reasoned about.
> It's stored on the hardware components such as the SoC, cellular radio, Wi-FI radio, etc. and gets loaded from there.
ie they have hardware
> This is a much less transparent approach
No, it's not. What's 'less transparent' is the use of proprietary blob firmware updates from "external researchers" in a neverending mess of irreducible complexity
> than not having firmware storage in components and the OS having to load it.
Again; this is what you want. You want purism to load proprietary firmware blobs, which of course they take issue with.
> and you're accusing *us* of redefining terms????
We're using the industry standard definition of it, it's you that's not.
> Not receiving proprietary firmware "updates"(ie proprietary blob exploits) is a good thing - it means the system has a fixed level of complexity and can be reasoned about.
Their hardware is a closed source black box. You're not reasoning about it. The firmware is harder to inspect, not easier. Updates do not prevent inspecting the firmware.
@jeffcliff @gcvsa Purism DOES ship and load proprietary blobs. They hide it from users and pretend it's not happening, but it is. They have proprietary hardware with proprietary firmware. Leaving known, verifiable vulnerabilities unpatched and using much lower security components without basic protections makes user privacy and security much worse off. Not having properly working MAC / probe randomization and the Wi-Fi firmware not even using early 2000s stack canaries / ASLR isn't a good thing.
> It's already installed. Not loading it or updating it from the OS doesn't make it not exist.
It makes it an informed decision on what the hardware is for that device, minimizing complexity of the hardware
@jeffcliff @gcvsa No, it doesn't. It's closed source hardware that's still a black box with closed source firmware stored on the hardware. Components having their own flash memory to store their firmware is much less transparent than the OS having to load it each boot. Users are much less aware of the firmware, but it's still there, and it's not any less privileged. A cellular radio could update itself remotely... but it's a whole lot more reasonable if the OS is responsible for updating it.
> Purism markets the device with extremely false claims about privacy, security and openness.
You keep making this accusation, and when called on it you keep being proven wrong.
> Providing basic privacy/security updates and protections is the bare minimum, and they don't
They do provide security and privacy updates, of course( Crimson development continues to this week too). Just not the ones *you* want (ie the proprietary ones) - ie you're completely full of shit on this.
@jeffcliff @gcvsa PureOS is lacking the most basic privacy and security protections. It's a fork of an OS with atrocious privacy and security including a history of introducing many vulnerabilities and only backporting a small portion of security patches which are assigned CVEs. Purism chooses not to ship firmware updates and goes out of the way to block them in some cases. They do not provide a working app sandbox, permission model, modern exploit protections or many other basic protections.
@jeffcliff You're peddling an unsafe option from a company that's scamming people for profit. Purism harms people by selling them overpriced low end hardware for outrageous prices while providing atrocious privacy and security. The hardware is closed source with closed source firmware. Not updating the firmware doesn't make it go away. Leaving known, veritably present vulnerabilities open is not protecting people. Hiding it from users and misleading them isn't at all freedom respecting.
> You're peddling an unsafe option
They are 'safe' against their threat model as it comes
> from a company that's scamming people for profit.
They ship hardware and software - they aren't a scam.
> Purism harms people by selling them overpriced low end hardware for outrageous prices while providing atrocious privacy and security
You keep accusing them of the latter, and every thread we encounter one another you're proven wrong. And the prices aren't that outrageous if your carrier isn't subsidizing it - it's comparable with other devices on the market.
> They are 'safe' against their threat model as it comes
It's proprietary hardware and proprietary firmware with atrocious privacy and security. Redefining words and making convoluted rules for what's okay and what's isn't based on ideology does not have to do with a threat model.
> They ship hardware and software - they aren't a scam.
It's a scam because they sell it by making many objectively false claims about what it provides.
> proven wrong
No such thing has happened.
@jeffcliff The prices have nothing to do with carriers subsidizing it. Purism is selling hardware which would be in the $100 and below range for unlocked, non-carrier device for the price of a high end flagship phone. They're selling it for that high price based on falsely claiming that their closed source, proprietary hardware and closed source, proprietary firmware are open/free which they're not. They're misleading people by claiming a closed source hardware product is open. It's wrong.
Again: this is a good thing. They aren't shipping proprietary firmware.
> They do not provide a working app sandbox,
"app sandbox" is an excuse to run proprietary software imho so this isn't super important.
> permission model, modern exploit protections or many other basic protections.
This of course is a blatant lie.
> Again: this is a good thing. They aren't shipping proprietary firmware.
Purism is shipping proprietary hardware and proprietary firmware with the device. They're leaving it non-updated without fixes for known, verifiable vulnerabilities both due to the end-of-life components and lack of OS updates for it. Not updating it doesn't mean there isn't proprietary firmware. It's still there. They blocked updating some of the firmware, not all of it, but they don't update it.
> "app sandbox" is an excuse to run proprietary software imho so this isn't super important.
Open source software still requires trusting the upstream developers and the downstream package maintainers. Open source does not mean all vulnerabilities or bad behaviors are known and resolved at all. Many severe vulnerabilities last for years or even decades in widely used and review projects like the Linux kernel.
> This of course is a blatant lie.
No, it's the absolute truth.
@jeffcliff @gcvsa PureOS and Debian do not have modern exploit mitigations. They aren't even using the standard upstream Linux kernel exploit mitigations, aren't using type-based control flow integrity, etc. They're still in the process of deploying early 2000s mitigations such as full ASLR. They're nowhere close to deploying hardened allocators, memory tagging, etc.
Having a proper permission model would requiring using sandboxing with a design providing that, which they aren't doing.
@jeffcliff @gcvsa They don't have full system MAC/MLS policies, they don't use sandboxing throughout the base OS or for apps in general beyond certain partial opt-in sandboxing, etc. They don't have verified boot but at most a useless incomplete desktop Windows Secure Boot approach. They do have software with versions frozen for years with very incomplete backports and many misguided downstream changes to configurations and code. An enormous number of additional people are trusted as part of it.
they have the ability to run software and 'apps in general' means 'proprietary software apps'
> They don't have verified boot
that's a good thing - drm locked bootloaders are not a good thing
> They do have software with versions frozen for years with very incomplete backports and many misguided
oh now they are misguided too? Talk about FUD
> An enormous number of additional people are trusted as part of it.
Not really - you can build the images yourself, you can audit the code yourself - the hardware is of course still trusted but since it's auditable...
> they have the ability to run software and 'apps in general' means 'proprietary software apps'
You can run proprietary software on that insecure OS without modern privacy and security protections too. Providing modern privacy and security protections is not enabling running proprietary software more than not doing it.
> that's a good thing - drm locked bootloaders are not a good thing
They have a proprietary, locked firmware early boot chain. Not updating != not existing.
> oh now they are misguided too? Talk about FUD
It's the truth, not FUD. Backporting a subset of patches with CVEs assigned for the vulnerabilities is only a small portion of overall privacy and security patches. Freezing the software versions for years is highly problematic. It's better when projects provide LTS releases with a much higher portion of backports but Debian usually ignores LTS versions other than specific cases where they can't keep up with CVEs otherwise.
> Not really - you can build the images yourself, you can audit the code yourself - the hardware is of course still trusted but since it's auditable...
Having the code and being able to audit it at a source code level does NOT mean you aren't trusted the developers and people making downstream changes to it. Reading all of the code does not mean you find all the vulnerabilities. In practice, only a small subset will be found. See how it actually works for the Linux kernel.
This is 100% bullshit. Debian is the gold standard of modern software, period.
> Having a proper permission model would requiring using sandboxing
Again, what you seem to be including as your 'modern security mitigations' is 'stuff designed so proprietary software is easier to run'
> This is 100% bullshit. Debian is the gold standard of modern software, period.
It's the direct opposite of that and objectively doesn't ship modern exploit mitigations. They haven't even started deploying type-based CFI or other basic protections. They're 20 years behind on it. You brought up them finally deploying full ASLR in an era where ASLR is an incredibly weak mitigation that's used because it's near free and trivial to deploy.
> Again, what you seem to be including as your 'modern security mitigations' is 'stuff designed so proprietary software is easier to run'
Allocator hardening, type-based control flow integrity, hardware memory tagging and many other modern exploit protections have nothing to do with making proprietary software easier to run. App sandboxing and a proper modern permission model with case-by-case control don't have to do with it either. You're just making absurd claims now.
> Open source software still requires trusting the upstream developers
uh no it doesn't
you should read every line of code in your project and verify what it does
BEFORE trusting it
> and the downstream package maintainers. Open source does not mean all vulnerabilities or bad behaviors are known and resolved at all.
Again this is you confusing 'open source' with 'free software' which you continually do. "Free software" Isn't a guarantee against every software bug --- it gives you the power as a community to resolve them
> Many severe vulnerabilities last for years or even decades in widely used and review projects like the Linux kernel.
Well no shit. But we have processes for dealing with them.
> No, it's the absolute truth.
No, it's not. Just checked and system binaries support PIE for example.
> you should read every line of code in your project and verify what it does
Even if you read every line of code in every project you used, you would still be trusting the developers. Reading every line of code does not mean you find every vulnerability. It's clearly not the case and fully contradicted by how finding vulnerabilities in open source actually happens. The Linux kernel has many severe vulnerabilities not caught for years or decades with many people reading it.
> Well no shit. But we have processes for dealing with them.
In this case, not backporting most of it.
> No, it's not. Just checked and system binaries support PIE for example.
PIE is for full ASLR. It's an early 2000s mitigation. It's the opposite of the modern mitigations being talked about. Debian taking 2 decades to start getting close to fully deploying the early 2000s mitigations while not providing modern exploit mitigations is the whole point of what we said.
> Again this is you confusing 'open source' with 'free software' which you continually do.
The ideology is different, but the requirements for both are the same. Actual open source software is free software too.
> it gives you the power as a community to resolve them
Other people cannot resolve the hardware and firmware issues in the Librem 5 because it's closed source hardware with closed source firmware. Not updating the firmware doesn't make it not exist, sorry.
Holy christ are you ever wasting my time today.
We went into this in the last thread. YOU are the one who takes issue with them not deploying proprietary firmware, you've done it over and over again, and every time you are called on it you leave the thread. They aren't 'end-of-life' components (that's a lie *because purism uses and supports them*)
> and lack of OS updates for it.
There is no 'lack of OS updates' -- they are updating the OS all the time. https://forums.puri.sm/t/pureos-crimson-development-report-september-2025/29822/12
> Not updating it doesn't mean there isn't proprietary firmware.
Yes it does, not updating with proprietary firmware means that the hardware is defined *as is*
@jeffcliff @gcvsa Purism deploys proprietary hardware and firmware. That's what their devices provide. Selling people devices with proprietary firmware but not providing patches for known, verifiable vulnerabilities is their approach.
What we're going to do is respond to your massive flood of false claims to promote these insecure products by making a long form post and sharing it across platforms. It's a waste of time responding to you pushing false claims about it, so we won't keep doing it.
@jeffcliff @gcvsa A lot of the Librem 5 firmware doesn't have updates blocked but it's generally not available due to the hardware components being ancient, low security ones which weren't ever going to provide proper long term support. They're not shipping patches for known, verifiable vulnerabilities. For the SoC, they've prevented themselves or others from doing some of it. They haven't fully blocked it for Wi-Fi, cellular, etc. but they chose components which aren't getting proper updates.
@jeffcliff @gcvsa Contrary to what you're saying, they do have serious issues with how the OS software is updated. The model of backporting only a small number of fixes to patch issues with known CVEs isn't one that works well. Most security issues in the open source projects which are used do not get CVE assigned. Projects expect that the new stable releases are shipped at some reasonable pace, not years with the version frozen. Projects with LTS versions also usually don't do it for years.
>Contrary to what you're saying, they do have serious issues with how the OS software is updated.
No, they don't. YOU claim there are, and when called on it it always turns out to be bullshit. You just don't like debian's development model. That's fine. That doesn't make debian stable-like distributions not the proper foundation for free software development
> The model of backporting only a small number of fixes to patch issues with known CVEs isn't one that works well.
Debian has decades of experience showing you are wrong
> Most security issues in the open source projects which are used do not get CVE assigned
red herring -- security updates are still deployed without them (i've deployed more than a few to debian stable personally)
>. Projects expect that the new stable releases are shipped at some reasonable pace
Oh now they aren't developing at a 'reasonable' pace well guess what? Maybe people would 'deploy faster' IF THEY WEREN'T WASTING TIME ARGUING WITH YOU ALL THE TIME
> Projects with LTS versions also usually don't do it for years.
This is mostly FUD. Security vulnerabilities get rolled out. LTS means that the project can be more predictable, and can be built upon by third parties
@jeffcliff @gcvsa Freezing software versions for years while backporting a small subset of privacy/security patches is not somehow the one true model for proper free software developers. It's an outrageously baseless and ridiculous claim. Free software is not at odds with providing recent stable releases of software or recent LTS releases.
> Debian has decades of experience showing you are wrong
Quite the opposite, they've proven their approach is highly insecure and that it doesn't work well.
> red herring -- security updates are still deployed without them (i've deployed more than a few to debian stable personally)
Debian's approach is tracking and backporting patches for vulnerabilities with CVEs assigned. Their policy is obtaining a CVE if they want to backport other security patches, which is very rare and an extremely tiny subset of the actual security fixes being done upstream. In most cases they don't even ship LTS releases such as for nginx.
> This is mostly FUD. Security vulnerabilities get rolled out. LTS means that the project can be more predictable, and can be built upon by third parties
Debian mostly doesn't use the LTS releases of upstream projects. Instead, they backport a much smaller subset of security fixes. It's a far smaller subset of the security patches than what gets backported by upstream projects providing LTS releases. CVE assignments are not actually done for all security vulnerabilities.
>What we're going to do is respond to your massive flood of false claims to promote these insecure products by making a long form post and sharing it across platforms.
You're the one who has been flooding our feed with false claims
> It's a waste of time responding to you pushing false claims about it, so we won't keep doing it.
PLEASE stop doing it. You are a complete and utter waste of time and every time you get into one of these threads you wind up wasting everyone's time with your false claims.
@jeffcliff @gcvsa It's you who is repeatedly making false claims and promoting scam products with false marketing. It's you who is wasting everyone's time. We'll be writing at least one in-depth article in response, which will reach at least 10000x more people than this thread even if we don't do more to spread it than a single post across our social media accounts. We're uninterested in spending unlimited time dealing with you repeatedly making the same false claims, we'll just make an article.
@jeffcliff @gcvsa It's completely true and you haven't prove anything wrong either here or elsewhere. You repeat the same false claims over and over again to market highly insecure and non-private proprietary hardware/firmware products from Purism.
https://snac.lx.oliva.nom.br/lxo/p/1750293340.123326
This is what you want them to do: to plug proprietary firmware blobs.
>e end-of-life components and lack of OS updates for it
There is no 'lack of OS updates' since they are still deploying OS updates.
>Not updating it doesn't mean there isn't proprietary firmware. It's still there.
The hardware is still there, yes.
@jeffcliff @gcvsa Not continuing to engage with people engaging in serial fabrications and manipulation is not running away. There's a limit to how much time we'll allow people like yourself to waste. As we said earlier, the fact that you're repeatedly doing this means we'll be writing a post debunking the highly insecure and non-private Librem 5 and other Purism hardware. You've pushed us to do that by continuing to come to threads about GrapheneOS to try to mislead people. That's on you.
@jeffcliff @gcvsa Purism sells proprietary hardware with proprietary firmware, which they falsely claim is open and free. They're scamming people.
Contrary to your claims, Purism does not provide proper OS updates but rather uses a model of freezing software for years with only a small subset of security patches backported. Only patching a subset of issues with CVEs assigned while letting software get years out of date is not a good approach, regardless of whether it's IBM or Purism doing it.
@jeffcliff @gcvsa We haven't made any false claims. It's you doing that, including right here. If you want us to write a long form post about this for our website or forum, so be it.
@jeffcliff @gcvsa What we've said about it is completely correct. Librem 5 has closed source hardware with closed source firmware. It doesn't avoid the closed source firmware, they just chose components with it stored within the components to avoid the OS loading it. For the SoC, they locked it in place to prevent users changing or updating it. It's users they prevented doing that for their own devices. Users don't get a choice or the option to set up verified boot with their own keys.
> Users don't get a choice or the option to set up verified boot with their own keys.
This is a good thing. 'Verified boot' means 'DRM-locked bootloader' and is exactly the kind of antifeature that the GPL3 was intented to stifle.
@jeffcliff @gcvsa We've said that it's not providing firmware updates, which is true. It leaves known, verifiable vulnerabilities unpatched. This is made much worse by their choice of much lower security components than the norm. Purism falsely claims their devices are open and free despite being closed source, proprietary hardware with closed source, proprietary firmware. They're interfering with funding and support for actual open hardware projects, which their devices pretend to be.
@jeffcliff @gcvsa Purism devices have a locked down early boot chain. Not supporting users using the keys of their choice verify an OS isn't somehow an improvement over providing it. What they're doing still has proprietary firmware and they go out of the way to lock it to prevent changing or updating it on the main SoC. They consider non-SoC components to not count in the same way and therefore don't block updating firmware for the Wi-Fi radio, etc. but it doesn't mean that it's available.
@jeffcliff @gcvsa Providing modern exploit protections, app sandboxing and a proper permission model with case-by-case consent does not mean supporting proprietary apps. You're very strangely conflating having app sandboxing including for use with the OS components with proprietary apps. That's completely absurd. Using sandboxing throughout the OS including a strong reusable OS sandbox which is then also reused for all third party apps is not somehow enabling or supporting proprietary apps more.
@jeffcliff @gcvsa Purism's approach is "just trust us and the component vendors" with the hardware and firmware, but there are serious security weaknesses and unpatched vulnerabilities which can be verified to be there. You make unsubstantiated claims about backdoors elsewhere while promoting products deliberately leaving security holes open. What do you call purposely having serious security flaws which are downplayed and covered up if not backdoors? That's what you're promoting.
@gcvsa Fairphone doesn't provide proper updates or security features. Their devices don't meet our basic hardware security and support requirements which are listed at https://grapheneos.org/faq#future-devices. They ship the yearly releases around a year late from the start, skip monthly/quarterly releases entirely and consistently ship the security backports and SoC driver/firmware patches 1-2 months late. They have no secure element which is essential for disk encryption and important for other features.
> With Google’s recent announcement that they will no longer be providing device trees for Pixel phones
There's no other Android OEM providing what Pixels provided prior to Android 16. It was never one of our hardware requirements and we've continued supporting Pixels without it. We've communicated that GrapheneOS development will continue, that existing Pixels will remain supported until end-of-life and that future Pixels will be supported if they meet the hardware requirements.
@gcvsa GrapheneOS is based on Android 16 and our releases based on Android 16 are available in our Alpha and Beta channels. Please read what we've said about this ourselves on this platform in the threads we've published about it. The future of GrapheneOS is not in doubt. Our threads have been misrepresented by multiple blogs, news sites, etc. Many cited content written by third parties on X and Telegram without verifying it. They inaccurately attributed claims made by someone else to us.
@GrapheneOS I’m sorry, I did not mean to imply that the future of Graphene is in doubt, I meant my future ability to access supported hardware is in some doubt. I am hoping that if I get a Pixel 9a this year, it will remain well-supported for its useful lifespan, and 4-5 years in the future, the landscape will have changed for the better.
@gcvsa We've confirmed 10th gen Pixels meet our requirements and will be adding support for them. A lot of progress has been made on it already but we need the Android 16 QPR1 tags to be published first. Our OEM partner can likely provide us early access to quarterly and yearly releases but we're unsure how long that's going to take. The details of what can be published without it being pushed to AOSP need to be worked out. We'll try to get things sorted out with them sooner rather than later.
DEC VAXstation soon™ at your local hackerspace
There it is
alright, so yesterday I tried to get the serial console going. the machine has 8 diagnostic LED's which signal its current state and it seems that it gets into a boot console I think.
Because this is a workstation machine, it has ~normal~ video output, VMS ran Xorg with CDE.
So video is the default output but there is a switch that allows you to change the default output to a serial console and there are two serial ports on the back, RS423 and weird RJ45 looking thingy
The weird serial output is called a Printer/Communication port, which uses MMJ connector. This is a fucking proprietary DEC connector for serial consoles, but it is based of RJ-12 with a displaced latch.
There is also a normal RS423, which is called a Communication/Printer port, which, in counterintuitively is not used by default at all. It is an arbitrary port you can pin a modem or a printer to.
The good news is that MMJ is compatible with RS-232.
So it should be easy to rip open a RJ-12 cable and solder respective MMJ pins to RS-232 pins.
Also, look at this video connector.
w t f is this
i've heard yall like os specific graphics APIs
look at this fucking thing
https://bitsavers.org/pdf/dec/vax/vms/gks/AA-HW45D-TE_VAX_GKS_4.1_User_Manual_199002.pdf
okay, fake news. the MMJ connector has pins on the top of the connector, while 6P6C has its on the bottom. So if you try to plug 6P6C to MMJ socket with the latch on top, it'll fit, except the pins are on the botton.
its time to learn 3d printing I guess
kay, update
I was gifted a 6P6C cable by someone :3.
I lobotomised this fucker.
After 1 bad soldering job and then 1 successful job, the oscilloscope showed me a flat line, so no signal from the vax.
diagnostic leds show that its 'enterING the console program', the continuous tense worries me a bit
this is your regular reminder that people who prefer light mode have a fucking condition, it's called astigmatism, look it the fuck up instead of calling us psychopaths. jesus fucking christ it's not 2015 anymore grow up
@eniko My bad!
No, but on a serious note, though, I heard (I think from you, actually?), that even people with astigmatism like dark mode as long as it's not pure white on pure black or something, and that it oft helps (?)
But I dunno if that's true, as my case is very mild
@me @eniko This is me, too. I deliberately got an apartment with a beautiful, panoramic view. I didn't consider at the time that that means it's often quite sunny in there.
My laptop screen isn't that bright. If I used dark mode in the daytime, all I'd see would be my own reflection in the screen!
OTOH, when the sun goes down, light mode is too bright.
I'm increasingly 😒 with web sites and apps that don't automatically switch mode along with my OS. (Reddit, WTF?)
POTION SELLER PUBLIC LICENSE
Copyright (c) <year> <copyright holders>
THIS SOFTWARE IS TOO STRONG FOR YOU, USER. YOU CAN'T HANDLE MY SOFTWARE. IT'S TOO STRONG FOR YOU. MY STRONGEST SOFTWARE WOULD KILL YOU, USER. YOU CAN'T HANDLE MY STRONGEST SOFTWARE. YOU'D BETTER GO TO A DEVELOPER WHO WRITES WEAKER SOFTWARE. YOU DON'T KNOW WHAT YOU ASK, USER. MY STRONGEST SOFTWARE WOULD KILL A SYSTEMS PROGRAMMER, LET ALONE A MAN. YOU NEED A DEVELOPER WHO WRITES WEAKER SOFTWARE, BECAUSE MY SOFTWARE IS TOO STRONG. YOU CAN'T HANDLE MY STRONGEST SOFTWARE. NO ONE CAN. I CAN'T GIVE YOU MY STRONGEST SOFTWARE, BECAUSE MY STRONGEST SOFTWARE IS ONLY FOR THE STRONGEST BEINGS, AND YOU ARE OF THE WEAKEST.
The above copyright notice and this permission notice shall be included in all copies or substantial potions of the Software.
Imagine a stranger spreads lies about you. They tell everyone you're doing horrible stuff, the worst crimes imaginable. They make videos, articles, livestreams, all pushing the same lies designed to make everyone hate and fear you.
Would you "just block them"?
What happens when other people don't block them? When other people believe them, follow them, share their lies?
What if this turns into real life abuse? If someone attacks you or your family?
This is what vulnerable minorities face because of badly-moderated social media:
🙏 Please defederate threads.net or ask your server admin to do so.
Them: “We should make open source sustainable”
Me: “Can I get paid for my work?”
Them: “Not like that!”
Our #fundraiser is off to a flying start, and the fun has just begun! Next week we're releasing #Plasma6.5.
One of our #birthday wishes is to continue delivering quality #FreeSoftware for the whole world to enjoy. Help us make it happen with your #donation:
If those "goodies" contain a cute autograph of Katie, count me in! 😁
(But seriously, I'll join in on that later, thanks for all your work!)
I just had a realization regarding @BrodieOnLinux recent video.
Those "KDE looks old" posts are all made by Leonardo DiCaprio alt accounts because it's older than 24 years!
@kde @kde@lemmy.kde.social Happy 39th Birthday! Can't believe it's been 39 years! 38 years for us GNOME folks following big sister. :)
@kde@floss.social @kde@lemmy.kde.social
Thanks for all the great work, providing a customizable and sensible free desktop environment for such a long time! 🙂
As a long-term user (20+ years), I've just donated. I hope it helps to fulfill your wishes. 👍
I've been trying a new way to turn procrastination into getting stuff done,by making a list of chores and rolling a D20 to see what I have to do next. Playing with the pretty dice and the randomness of it all is easier for me at the moment than "just do it". I know this will only work for a bit, I'm learning that this is how my brain works, a few weeks from now I'll have to change it up and that's ok.
@Zumbador @autistics I absolutely love that idea and now I'm thinking about how to include rolling ability checks and level ups into this.
@vger @Zumbador @autistics that should be step two, once you get bored 😄
@llPK @autistics @vger @Zumbador would https://en.wikipedia.org/wiki/Habitica be useful here, or is that a different category?
Building the go module "forgejo.org" will never not be funny to me
@linus @famfo if you ever buy frogejo.org please give me dns access
what’s your favoourite game? mine is Processing Vulkan shaders (2%)
htop gaming (it’s RGB)
@domi is that a 20(???) core cpu or is there a third column im not seeing that makes it normal somehow
i'd guess it's one of intel's new-fangled hetero processors
id guess that too since they do have at least 1 processor with 20 cores
>>> Emerging (37 of 476) dev-qt/qtwebengine-6.9.2-r1::gentooexcellent gameplay!! I always tear up a little when I get to this point:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict
@domi i'm absolutely convinced that the time it takes to preprocess the shaders on average is more than the sum of all frame time differences you'll get for the entirety of the gameplay time if you skip it
@domi processing vulkan shaders (71%)
clicks skip cause no progress since 15mins or so
game window opens
crashes
ty valve
Chwilowy burst produktywności wykorzystałam na kolejne przejrzenie ubrań i wyprzedaż majątku.
Celuję w minimalizm i żeby było jak najmniej noszenia kiedy się w końcu wyprowadzę.