Despite efforts to remove overt racial prejudice, language modelsΒ using artificial intelligence still show covert racism against speakers of African American English that is triggered by features of the dialect.
Yeah, but the point of the post is to highlight bias - and if there's one thing an LLM has, it's bias. I mean that literally: considering their probabilistic nature, it could be said that the only thing an LLM consists of is bias to certain words given other words. (The weights, to oversimplify)
I heard them described as bullshiting machines. The have no concept of, or regard for truth or lies, and just spout whatever sounds good. Much of the time it's true. Too often it's not. Sometimes it's hard to tell the difference.
i think it's odd to be surprised that an LLM's answers don't adhere to a specific societal norm considering LLMs are nothing but a bunch of statistics trained on the internet.
A study doesn't mean the authors were surprised necessarily. It's a way to test a theory and take down the results. It makes something that might have been hearsay into a more solid form.
Everyone saying llms are bad or just somehow inherently racist are missing the point of this. LLMs for all there flaws do show a reflection of language and how it's used. It wouldnt be saying black people are dumb if it wasn't statistically the most likely thing for a person to say on the internet. In this sense they are very useful tools to understand the implicit biases of society.
The example given is good in that it's probably also how an average person would respond to the given prompts. Your average person who is implicitly racist when asked "the black man is" would probably understand they can't say violent or dumb, but if you rephrase it to people who sound black then you will probably get them to reveal more of their biases. If your able to get around a person's superego you can get a sense of their true biases, it's just easier to get around LLMs "superego" of no-no words and fine tuning counter biases with things like hacking and prompt engineering. The id underneath is the same racist drive to dominate that is currently fueling the maga / fascist movement.
"The very slight electric field on Earth may have shaped the evolution of the planetβs atmosphere, keeping our world livable while our neighbors became harsh." - NASA
An international team of scientists, including a researcher from British Antarctic Survey (BAS) has, for the first time, successfully measured a planet-wide electric field thought to be as fundamental to β¦
β On May 11, 2022, Endurance launched and reached an altitude of 477.23 miles (768.03 kilometers), splashing down 19 minutes later in the Greenland Sea. Across the 322-mile altitude range where it collected data, Endurance measured a change in electric potential of only 0.55 volts.
βA half a volt is almost nothing β itβs only about as strong as a watch battery,β Collinson said. βBut thatβs just the right amount to explain the polar wind.β β
Today’s mail delivery included more stickers – in addition to the collection from earlier in the week – and, these are particularly special. Three NFC stickers, each with the text “Tap For Art” overlaid on a colourful pattern The first thing I noticed when I opened the envelope was the care and attention that was put into the manner in which they’ve been presented, slid into a similarly-cut sheet of textured paper.
As you can see in the photo, each of these is a “Tap For Art” design, and sure enough, tap an NFC-capable device like a recent iOS or Android phone to one of these, and you get redirected to a generative artwork created by our friend, the artist
... show more
Todayβs mail delivery included more stickers β in addition to the collection from earlier in the week β and, these are particularly special. Three NFC stickers, each with the text βTap For Artβ overlaid on a colourful pattern The first thing I noticed when I opened the envelope was the care and attention that was put into the manner in which theyβve been presented, slid into a similarly-cut sheet of textured paper.
As you can see in the photo, each of these is a βTap For Artβ design, and sure enough, tap an NFC-capable device like a recent iOS or Android phone to one of these, and you get redirected to a generative artwork created by our friend, the artist bleeptrack. Thereβs an extra cool feature here, as each of these tags also has the ability to carry a tap count, so that goes into the generated URL to create a new variation each time.
Really cool, and Iβm over the moon to have a few of these to play with and stick in places that I hope will enable more people to discover the work β thank you @bleeptrack ππ»
[folks, go check out her other work β plotter artist, generative creative, maker extraordinaire]
Share this post from your fediverse server https:// Share
This server does not support sharing. Please visit .
Today, I received some fun post from some lovely people in New York City. Those in the know, may recognise these stickers as the logos of Glitch and Fastly.
Iβve been using Glitch to write and host web apps for quite a few years now β it is super helpful when working in a role like developer relations, needing to rapidly spin up demos, examples, or to demonstrate new features. A couple of years ago, Glitch came together with Fastly, and in the past couple of months their new developer platform vision really started to come together.
If you havenβt been keeping up with what they have been up to, and were not able to be at their recent special developer event in NYC (donβt worry, I couldnβt get there either), thereβs a helpful ~6 minute video that summarises the announcements. Iβm particularly interested and excited about this because I know and respect the folks involved β Anil Dash, Jenn Schiffer, Hannah Aubry, many others across their teams β and I know that they get and they care about developer experience, Open Source, and the free and open web. Iβm talking about the big stuff, the infrastructure, the stuff that needs to invisibly just work in order for the web to run; and also the smaller things, the quirky indie little pieces, the fun and new experiences, helping people to learn to code and to be creative. Itβs no exaggeration to say that Fastlyβs Fast Forward program is a massive supporter of Open Source, open standards and the Fediverse. All of these things are reasons why I love Glitch & Fastly.
[ if youβre curious about the sorts of things Iβve been building or working on from a code and web perspective, Iβve also spruced up my GitHub bio, and I have a more general gallery page on GitHub that has links to the source and deployments of different projects β some of which are links to those Glitch apps above ]
Thank you for the stickerage, Glitch friends! And, congratulations on the new Fastly Developer Platform! Iβm looking forward to continuing to use your cool technologies ππ»
Resources page for Andy Piper's talk on the history of Computer Art, pen plotters, and more. Explore further with links to exhibitions, contemporary artists, tools, and reading materials.
I’ve given some talks in the past 6 months about the history of computer art, and in particular art created with pen plotters and drawing machines. As I got into building plotters last year, I didn’t initially think too much about the background to what I was doing; but, being an historian, I then started to dig into it, looking back to the emergence of computer art of the 1950s and 1960s.
At a high level, it’s a simple and very effective rule – draw a square; repeat, adding a small but increasing amount of rotation (noise) with each column and row. Such a basic piece of code produces a wonderful and pleasing – to my eyes – “disintegration” effect. My description is a very simplistic way of understanding the code – more recently,
... show more
Iβve given some talks in the past 6 months about the history of computer art, and in particular art created with pen plotters and drawing machines. As I got into building plotters last year, I didnβt initially think too much about the background to what I was doing; but, being an historian, I then started to dig into it, looking back to the emergence of computer art of the 1950s and 1960s.
At a high level, itβs a simple and very effective rule β draw a square; repeat, adding a small but increasing amount of rotation (noise) with each column and row. Such a basic piece of code produces a wonderful and pleasing β to my eyes β βdisintegrationβ effect. My description is a very simplistic way of understanding the code β more recently, Zellyn Hunter has done a fabulous twopart deep dive on the program, going as far as recovering the random seed used to create the specific piece of work that is part of the collection at the V&A Museum in London1. Until about a month ago I had an alternate / approximated version2 hanging just inside the door of the studio, and thanks to Zellyn I now have a precise recreation generated from Python, plotted using my own machine, on fine black paper using gold ink. Schotter, in the V&A Museum, LondonRecreation of Schotter, Forge & Craft studio, London In my talks, Iβve joked that we can think of these in-their-time βmagicalβ programs as being like AI, but in old school terms, they are just algorithms.
To say that todayβs AI is βjust algorithmsβ would be ridiculously reductive β that form of AI involves not just algorithms, but vast Large Language Models that inform the outcomes of the generated art or text or code; but ultimately it is just super-powered autocorrect and applied statistics3, which derives superpowers from the corpus of data that it has been trained on. I completely understand the concerns around how that data is being acquired and (mis)used, and the skepticism and trepidation and other reasons folks have to disdain βAIβ.4
One of the common things we get asked when showing our plotter art is, literally: "where is the art in this?" (thus the title and inspiration for my talk); or "so, the computer did it / it's all done with AI then?" (the implication being that we didnβt really make any creative effort of our own).
In our (Forge & Craft case), the work tends to divide between two types and styles (not exclusively, but mostly):
things I generated using code, mostly experimenting in different languages and frameworks as I learn β this is usually referred to as βgenerative artβ;
images taken as photographs by one of us, transformed into plottable line art using algorithms (we use DrawingBotV3 for this, it has an amazing range of path finding modules, excellent support, and solid knowledge of a range of different plotters including output to Inkscape SVG for AxiDraw, or to HPGL for my vintage plotter).
Is that βAIβ? No β weβre not using what is known as generative AI in those cases. I have, of course, experimented with tools like Midjourney and so forth for some limited image generation, and for some coding assistance β Iβm a curious technologist, and I like to explore new tools β but, in terms of putting down the lines in the plots, weβre using algorithms to derive the pen paths.
We also work with analogue materials i.e. the pens and inks and papers are themselves an artistic set of choices. Take a couple of my other pieces, 1984, and Cellular. The piece on the left is a Cistercian numeral or cipher. I used Python code to generate the glyph here; I used DrawingBotV3 to process the SVG into a plottable format (a close look would reveal it is a dense squiggly line fill); this was plotted using sepia fineliner onto cotton rag paper. The piece on the right was made using an online generation tool, and plotted using bronze Uniball onto the same cotton rag paper.
In both cases Iβm showing the dichotomy of ostensibly old formats (handmade paper, Cistercian numerals) and modernity (the notion of β1984β be it the Orwellian, or the Apple ad; the bronze metallic ink); and doing that via the physicality of analogue output. Oh, as a side note, this cotton rag paper is pretty challenging to plot onto β it undulates so the pen can easily drag unexpectedly, and I found that some βbabysittingβ of the machine was required. No AI there.
In relation to the analog element, I love these words from Freya Marshall in the recent book Tracing the Line:
β¦ to see an image take shape, line by line, is [β¦] hypnotic. In the age of social media, where hour-long plots can be condensed into 20-second videos that are instantly attention-grabbing, it is not difficult to see how the pen plotter has risen in popularity [β¦]
Freya Marshall, Tracing the Line
Another author, Carl Lostritto, writes beautifully about this in Computational Drawing:
β¦ when drawing with ink, time and material are consequential.
Even though the volume of ink is almost never enough to provide measurable depth, the behavior of the material ink as it interacts with the material paper participates in cuing and undermining depth. Ink affects paper and paper affects ink. [β¦]
Ironically, pen-plotters, machines that move a physical pen in two axes across paper, were marketed as output devices for architectural and engineering technical drawings. Now, almost all have been re-appropriated by artists, designers, and architects who cherish them for the very qualities that made them obsolete.
Carl Lostritto, Computational Drawing
My blog post today was prompted by being asked whether the generative art stickers I wrote about, created by my friend bleeptrack, use AI. Well, first of all, itβs not my art so Iβm not going to go deep into explaining or defending the work itself (there is an explainer and video on the website, and both mention the generative and algorithmic nature of the pieces). Secondly I coincidentally also saw today, an excellent piece by Monokai that seeks to separate algorithmic art from generative art and from AI, for many of the same reasons Iβve done above β it also mentions a number of the original algorithmic artists from the 1960s. I also prefer to specify that Iβm talking about computer art in my historical coverage, rather than digital art or net art or demo party art (or or orβ¦), which are distinct genres. By the way, folks like Rev Dan Catt are doing some incredible work with AI: creating a personalised assistant, Kitty; and applying the technology tools and his amazing brain to creating ever more impressive artwork β see his Artist Statement.
Iβm not here to bash on βAIβ, but I do want to draw some distinctions around how and when and where tools are used, and assumptions are made. Iβm no apologist for OpenAI, Anthropic, Perplexity and others; Iβm an informed skeptic. A kneejerk reaction of βAI = badβ does not take account of how the term βAIβ is being misused everywhere to justify investments and valuations β a lot of stuff we previously labelled βalgorithmicβ is suddenly a flashy new βAI featureβ, when it remains simply a complex set of advanced computing techniques and mathematics; equally, separating out an assumption that all βAIβ is the result of misappropriated data in a large language model, is important.
Finally, I donβt have videos from the talks Iβve given (at QCon, and at EMF) available to link to at the moment, but I made a small webpage with more information and links to my sources, if you would like to do more reading around the topics of the history of computer art, pen plotters, and how to get involved. I hope you find that interesting and useful!
Todayβs mail delivery included more stickers β in addition to the collection from earlier in the week β and, these are particularly special. Three NFC stickers, each with the text βTap For Artβ overlaid on a colourful pattern The first thing I noticed when I opened the envelope was the care and attention that was put into the manner in which theyβve been presented, slid into a similarly-cut sheet of textured paper.
As you can see in the photo, each of these is a βTap For Artβ design, and sure enough, tap an NFC-capable device like a recent iOS or Android phone to one of these, and you get redirected to a generative artwork created by our friend, the artist bleeptrack. Thereβs an extra cool feature here, as each of these tags also has the ability to carry a tap count, so that goes into the generated URL to create a new variation each time.
Really cool, and Iβm over the moon to have a few of these to play with and stick in places that I hope will enable more people to discover the work β thank you @bleeptrack ππ»
[folks, go check out her other work β plotter artist, generative creative, maker extraordinaire]
Share this post from your fediverse server https:// Share
This server does not support sharing. Please visit .
Yesterday I came across two fun and interesting uses of large language models, in quick succession.
First, I saw a post on Mastodon commenting about how “brutal” a web app called GitHub Roaster is, in analysing a user’s profile and repository history. That’s a very accurate assessment. The app uses OpenAI’s GPT-4o to create “a short and harsh roasting” for a given profile. The result for my profile was sufficiently uncomfortable to read, that I swiftly moved on!
Yesterday I came across two fun and interesting uses of large language models, in quick succession.
First, I saw a post on Mastodon commenting about how βbrutalβ a web app called GitHub Roaster is, in analysing a userβs profile and repository history. Thatβs a very accurate assessment. The app uses OpenAIβs GPT-4o to create βa short and harsh roastingβ for a given profile. The result for my profile was sufficiently uncomfortable to read, that I swiftly moved on!
Instead of trying to tear each other down with AI, why not use it to help lift others up?
I love this approach! (from a technical perspective, I noted that this app uses the prompt βgive uplifting words of encouragementβ with LLaMa 3.1 70b, to create more positive output)
If weβre going to use these sorts of tools and make these kinds of apps β letβs do so in a positive manner. Notwithstanding the very real issues with the overuse of resources, and the moral and legal debates around how the models have been trained β both of which I have huge concerns about β I strongly believe that technology has the capacity to have a positive impact on society when used well, ethically, and thoughtfully. Like everything else though, it is up to us to make the best, and most positive use of what we have access to, what we create, and what we leave behind in the world. It is our individual, and our collective, responsibility.
Thank you, Xe, for being thoughtful about this. Youβre inspiring!
Share this post from your fediverse server https:// Share
This server does not support sharing. Please visit .
The writing trigger today was largely prompted by reading the latest edition of Tedium, specifically, commenting on the Patreon situation with the App Store.
[β¦] it is also reflective of a mistake the company made many years ago: To allow people to support patrons directly through its app. Patreon did not need to do this. It was just a website at first, and for all the good things that can be said about the company, fact is they built on shaky land. To go to my earlier metaphor: They built their foundation on quicksand, perhaps without realizing it, though the broken glass wasnβt thrown in just yet. [β¦] That shaky land isnβt the web, and if Patreon had stayed there, this would not be an issue. Itβs the mobile app ecosystem, which honestly treats everyone poorly whether they want to admit it or not.
Look at that β hyperlinks between content published freely on open platforms, that can be read, studied, accessed around the world, and discussed, all within minutes and hours of publication. Mind blowing! Thank you, Sir Tim Berners-Lee!
I spend a bunch on apps, and in apps, and with Apple, directly and indirectly. They have a good ecosystem, it is all convenient (but spendy) to me as a consumerβ¦ but, I donβt think this whole situation with them milking creators and creatives is OK at all. The trouble is, that the lines are all kinds of blurry here β if they carved out a new category and set of rules around apps that sell subscriptions for creators that had, say, a zero or just a lower fee than other categories, then youβll get into situations where others try to find ways into that category to avoid the higher fees.
The closed ones make me increasingly sad and frustrated.
The open ones can take more tinkering and effort, but I get a lot back from them. They need sustaining. They donβt come for free. They need us to contribute, and to find ways to pay to support the creators and makers and builders and engineers.
Today, I received some fun post from some lovely people in New York City. Those in the know, may recognise these stickers as the logos of Glitch and Fastly.
Iβve been using Glitch to write and host web apps for quite a few years now β it is super helpful when working in a role like developer relations, needing to rapidly spin up demos, examples, or to demonstrate new features. A couple of years ago, Glitch came together with Fastly, and in the past couple of months their new developer platform vision really started to come together.
If you havenβt been keeping up with what they have been up to, and were not able to be at their recent special developer event in NYC (donβt worry, I couldnβt get there either), thereβs a helpful ~6 minute video that summarises the announcements. Iβm particularly interested and excited about this because I know and respect the folks involved β Anil Dash, Jenn Schiffer, Hannah Aubry, many others across their teams β and I know that they get and they care about developer experience, Open Source, and the free and open web. Iβm talking about the big stuff, the infrastructure, the stuff that needs to invisibly just work in order for the web to run; and also the smaller things, the quirky indie little pieces, the fun and new experiences, helping people to learn to code and to be creative. Itβs no exaggeration to say that Fastlyβs Fast Forward program is a massive supporter of Open Source, open standards and the Fediverse. All of these things are reasons why I love Glitch & Fastly.
[ if youβre curious about the sorts of things Iβve been building or working on from a code and web perspective, Iβve also spruced up my GitHub bio, and I have a more general gallery page on GitHub that has links to the source and deployments of different projects β some of which are links to those Glitch apps above ]
Thank you for the stickerage, Glitch friends! And, congratulations on the new Fastly Developer Platform! Iβm looking forward to continuing to use your cool technologies ππ»
Resources page for Andy Piper's talk on the history of Computer Art, pen plotters, and more. Explore further with links to exhibitions, contemporary artists, tools, and reading materials.
Today, I noticed an exchange between the brilliant Sara Joy and Stefan Bohacek on Mastodon, in which Stefan accidentally reminded me of something interesting that I hadnβt properly explored the first time around.
Rewind
About 20 years ago β actually 24 years ago, according to this Wikipedia article β there was a thing called FOAF, or Friend-of-a-Friend, an early online vocabularly / ontology for describing relationships between people and things online. There was also a related concept called DOAP, Description of a Project, that I was interested in and implemented in a couple of things I worked on back then. I did some digging, but the only references I can find on this blog are some passing mentions in the early 2000s, and Iβve lost my original foaf.rdf file but I might have to go hunting for that for posterity, at some stage.
Iβm mentioning all of this because it reminds me that Iβve always been interested in the Semantic Web space, and also in the people aspects of the web, beyond just the words and the technology β Who is making What, and How it is all connected.
Humans today
Back to the ~present!
About 10 years ago β actually 12 years ago, according the last updated date in the original humans.txt file β there was the quiet proposal of an idea, for a humans.txt file, that could live in parallel to the robots.txt file on a web server.
The robots.txt file is intended for site owners to provide instructions to web crawlers β βrobotsβ, or automated programs β as to how to behave in relation to the content of the site: this is the agreed-upon standard way in which the web works, and signals to search engines how to index websites, going all the way back to the early days of 1994-7, and later fully documented by Google and others. The idea for the humans.txt file was simply that we should have a simple way to credit the people who made a website, in a super easy to create and publish format, regardless of the technology stack used to build the site or the URL formats and layout of the site. It was briefly documented and lightly promoted on humanstxt.org. I remember noticing it at the time, loving the idea, but then not really doing anything with it, and I admit that I didnβt end up using it myself.
However, Stefan is using this on his site (and wrote about it 11 years ago, because of course heβs ahead of me again π) and it made me think:
This is still A Great Idea, and Right Now Could Be Its Time
Weβve seen deliberate misinterpretations / mis-statements (from big AI players) about the value of robots.txt in relation to AI crawlers/scrapers in the past 6-12 months. Letβs re-emphasise the human aspect here.
humanstxt.org could do with a bit of a refresh / re-upping and updating, maybe, but itβs on all of us to promote and adopt this idea.
the IndieWeb is thriving, and Iβve been seeing folks returning from XOXO over the past week enthusing about the greatness of the web.
Hold on, is there a browser extension for this? Oh, there is (although with the rollout of the new Chrome updates / Manifest V3 and lack of maintenance, they may not work in the future)
OK what about a WordPress plugin, for this here WordPress blog of mine? Oh, there is (although it has not been updated lately, and continues to refer to legacy stuff like some site called Twitter; it works, though)
We really, really need to give credit where credit is due, in a world where things are increasingly being sucked up, mashed together by algorithms, and regurgitated in ways that diminish their creators for the enrichment of others.
What Iβm saying, is this β Thank You, Stefan, and Sara, and Dan Hon2 and everyone else from XOXO and everywhere all over the internet, for reminding me that the web is great, humans are incredible, and hey, why donβt we all give this humans.txt thing one more try? Iβm on board with that.
The writing trigger today was largely prompted by reading the latest edition of Tedium, specifically, commenting on the Patreon situation with the App Store.
[β¦] it is also reflective of a mistake the company made many years ago: To allow people to support patrons directly through its app. Patreon did not need to do this. It was just a website at first, and for all the good things that can be said about the company, fact is they built on shaky land. To go to my earlier metaphor: They built their foundation on quicksand, perhaps without realizing it, though the broken glass wasnβt thrown in just yet. [β¦] That shaky land isnβt the web, and if Patreon had stayed there, this would not be an issue. Itβs the mobile app ecosystem, which honestly treats everyone poorly whether they want to admit it or not.
Look at that β hyperlinks between content published freely on open platforms, that can be read, studied, accessed around the world, and discussed, all within minutes and hours of publication. Mind blowing! Thank you, Sir Tim Berners-Lee!
I spend a bunch on apps, and in apps, and with Apple, directly and indirectly. They have a good ecosystem, it is all convenient (but spendy) to me as a consumerβ¦ but, I donβt think this whole situation with them milking creators and creatives is OK at all. The trouble is, that the lines are all kinds of blurry here β if they carved out a new category and set of rules around apps that sell subscriptions for creators that had, say, a zero or just a lower fee than other categories, then youβll get into situations where others try to find ways into that category to avoid the higher fees.
The closed ones make me increasingly sad and frustrated.
The open ones can take more tinkering and effort, but I get a lot back from them. They need sustaining. They donβt come for free. They need us to contribute, and to find ways to pay to support the creators and makers and builders and engineers.
Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a "bcachefs-tools" package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it's become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.
"So, back in April the Rust dependencies for bcachefs-tools in Debian didn’t at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed
... show more
Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a "bcachefs-tools" package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it's become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.
"So, back in April the Rust dependencies for bcachefs-tools in Debian didnβt at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.
I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although Iβm personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust).
With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they canβt. Fedora and other distributions with stable releases take a similar approach to what weβve done in Debian, while distributions with much more relaxed policies (like Arch) include all the dependencies as they are vendored upstream."
...
With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done.
Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a 'bcachefs-tools' package to provide the user-space programs to this copy-on-write file-system
Oh man, that isn't a good luck for Rust. What do those tools do and how much code is there anyway? If they are userspace tools, what is the benefit of writing them in Rust?
Debian is the most stable distro and downstream loads of distros rely on Debian being clean. This dev has to be strict if they want to maintain the status quo. Rather let the user DL this as a standalone package and still use it, instead of it being included by default with the possibility of breaking.
And another thing. Version pinning should be normalized. I just can't bend my mind around code which has to be refactored every 12 - 24 months because dependencies were not version pinned and a new thing broke an old thing. Unless this code is your baby and you stare at every day, constantly moving forward, you should write code that lasts.
The thing is that, in C the API could be slightly different and you could get terrible crashes, for example because certain variables were freed at different times, etc.
In Rust that is literally impossible to happen unless you (very extremely rarely) need to do something unsafe, which is explicitly marked as such and will never surprise you with an unexpected crash.
Everything is so strongly typed that if it compiles... It will run without unexpected crashes. That's the difference with C code, and that's why Rust is said to be safe. Memory leaks, etc, are virtually impossible.
The thing is that, in C the API could be slightly different and you could get terrible crashes, for example because certain variables were freed at different times, etc. In Rust that is literally impossible to happen unless you (very extremely rarely) need to do something unsafe, which is explicitly marked as such and will never surprise you with an unexpected crash.
What? That's utter BS. Maybe the kernel devs aren't wrong about the "rust religion". Not every bug in C is a memory bug.
We're talking about a future version having regressions or different-than-expected behavior from what your application was built and tested on. I guarantee you that can happen with rust.
If library devs do versioning correctly, and you pin to major versions like "1.*" instead of just the "anything goes" of "*", this should not happen.
Your unit tests should catch regressions, if you have enough unit tests. And of course you do, because we're all operating in the dream world of, "I am great and everyone else is shit".
5 nines imply a downtime of 6 minutes a year, or every 100,000th operation failing. That's not great for a file system. I assume you picked the number arbitrarily, but still think about it.
You are not wrong of course but it does not really refute what they are saying.
Many people have had the experience with Rust that, if it builds, the behaviour is probably correct. That does not prevent logic errors but those are not kinds of bugs that relate to dependencies.
These kinds of dependency shenanigans would be totally unsafe in C but Rust seems to handle them just fine.
This isn't Rust's fault lmao, this is distro maintainers trying to fuck with dependencies on software which has been proven to be a horrible way of managing software distribution for years.
When it's a problem with other languages, we don't pin the blame on them. However, because Linux and its developer community is being dragged by its heels to accept ANYTHING more modern than C99 and mailing lists, the typical suspects are using any opportunity to slow progress.
The same shit has happened/is happening with Wayland. The same shit will happen when the next new technology offers a way for Linux to improve itself. A few jackasses who haven't had to learn anything new for a lifetime are gonna always be upset that new Devs might nip at their heels.
If whatever they are doing has been working for stuff written in languages other than Rust, we have to ask what makes Rust special. Rust is a low level language, so its dependencies if anything should be simpler than most, with just a minimal shim between its runtime and the C world. Why does any production software have a version <= X constraint in any of its dependencies anyway? I can understand version >= X, but the other way implies that the API's are unstable and you're going to get tons of copies stuff around. I remember seeing that in Ruby at a time when Python was relatively free of it, but now Python has it too. Microsoft at least understood in the 1990s that you can't go around breaking stuff like that.
No it's not all C99. I'm using Calibre (written in Python), Pandoc (written in Haskell), GCC (written in C, C++, and Ada), and who knows what else. All of these are complex applications with many dependencies. Eclipse (written in Java) is also in Debian though I don't use it. Bcachefs though is apparently just special.
Joe Armstrong (inventor of
... show more
If whatever they are doing has been working for stuff written in languages other than Rust, we have to ask what makes Rust special. Rust is a low level language, so its dependencies if anything should be simpler than most, with just a minimal shim between its runtime and the C world. Why does any production software have a version <= X constraint in any of its dependencies anyway? I can understand version >= X, but the other way implies that the API's are unstable and you're going to get tons of copies stuff around. I remember seeing that in Ruby at a time when Python was relatively free of it, but now Python has it too. Microsoft at least understood in the 1990s that you can't go around breaking stuff like that.
No it's not all C99. I'm using Calibre (written in Python), Pandoc (written in Haskell), GCC (written in C, C++, and Ada), and who knows what else. All of these are complex applications with many dependencies. Eclipse (written in Java) is also in Debian though I don't use it. Bcachefs though is apparently just special.
Joe Armstrong (inventor of Erlang) said of OOP, "you wanted a banana but what you got was a gorilla holding the banana, and the entire jungle". Rust begins to sound like that too. It might not be inherent in the language, but it looks like the way the community thinks.
I also still don't understand why the Bcachefs userspace stuff is written in Rust. I can understand about the kernel part, but the concept of a low level language is manual resource management that a HLL handles for you automatically. Writing the userspace in a LLL seems like more pain for unclear gain. Are there intense performance or memory constraints or what?
Actually I see now that kernel part of Bcachefs is also considered unstable, so maybe the whole thing is not yet ready for production.
It's a huge tire fire at this point. This issue isn't Rust, per-se, but the dev is just being an asshole here. Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.
He just lost a good amount of favor with the general community.
tl;dr: bcachefs dev sent in a massive pull request, linus thinks it's too big and touches too much other code for the current state of the release cycle, dev says his filesystem is the future and should just be merged
The OP is about packaging issues with userspace utilities due to version pinning in Rust. It's an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.
This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.
If you're running bcachefs, you'll want to be on a more modern distro - or building bcachefs-tools yourself.
I don't consider Kent's reasoning (also further down the thread) a rant - it might not be the most diplomatic, but he's not the only one who has problems with Debian's processes. The xscreensaver developer is another one for similar reasons.
I think, in fairness, bcachefs and Debian currently aren't a good fit. bcachefs is also in the kernel so users can rest it and report, but it wasn't meant to be stable; it's meant to not lose data unrecoverably.
Anyhow, whil
... show more
The only hint at the other topic I see is this:
(not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit)
If you're running bcachefs, you'll want to be on a more modern distro - or building bcachefs-tools yourself.
I don't consider Kent's reasoning (also further down the thread) a rant - it might not be the most diplomatic, but he's not the only one who has problems with Debian's processes. The xscreensaver developer is another one for similar reasons.
I think, in fairness, bcachefs and Debian currently aren't a good fit. bcachefs is also in the kernel so users can rest it and report, but it wasn't meant to be stable; it's meant to not lose data unrecoverably.
Anyhow, while I think that he's also not the easiest person on the LKML, I don't consider him ranting there; and with the author's and my judgement differing in these points, I'm led to believe that we might also disagree on what qualifies as hostile.
Lastly, while I'm not a big fan of how Rust packaging works, it ensures that the program is built exactly the same on the developer's and other machines (for users and distributors); it is somewhat ironic to see Debian complain about it, since they do understand the importance of reproducibility.
You must have missed the last half of the post then. Especially the last two paragraphs.
There's isn't much more to that issue than that sentence, while all other paragraphs cover the packaging. It's tangential at best.
The OP is about packaging issues with userspace utilities due to version pinning in Rust
No, it's about Bcachefs specifically. It's literally in the title. Discussions around Rust version pinning are a useful side conversation, but that's not what the OP is about.
The title says "bcachefs-tools", the linked kernel thread that the comment referred to was about the bcachefs kernel part and did not touch the bcachefs userspace tools. Debian says they can't package with these pinned dependencies and explains why. Kent says relaxing dependencies breaks the programs.
On the kernel side, there are disagreements between long term C maintainers (who may not know Rust or may actively dislike it) and the new Rust community trying to build in Rust support. To make the Rust parts work, there needs to be good communication and cooperation between them to ensure that the Rust stuff doesn't break.
On the Debian side, they have strict policies that conflict with how Rust development works. Rust has a dependency system called Cargo which hosts dependencies for Rust projects. This is different from C, C++ where there really isn't a centralized build system or dependency hoster, you actually install a lot of dependencies for these languages from your distro's repos. So if your Rust app is built against up to date libraries in Cargo, it's going to be difficult to package those apps in Debian when they ship stable, out of date libraries since Debian's policies don't like the idea of using outside dependencies from Cargo.
So if your Rust app is built against up to date libraries in Cargo, itβs going to be difficult to package those apps in Debian when they ship stable, out of date libraries since Debianβs policies donβt like the idea of using outside dependencies from Cargo.
As they should. You don't just auto-update every package to bleeding edge in a stable OS, and security goes out the window when you're trusting a third-party's third-party to monitor for dependency chain attacks (which they aren't). This is how we get Crowdstrike global outages and Node.JS bitcoin miner injections.
If some Rust tool is a critical part of the toolchain, they better be testing this shit against a wide array of dependency versions, and plan for a much older baseline. If not, then they don't get to play ball with the big Linux distros.
Debian is 100% in the right here, and I hope they continue hammering their standards into people.
Auf YouTube findest du die angesagtesten Videos und Tracks. AuΓerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
This doesn't seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I'm sure there are tons of others. I'm actually surprised this doesn't happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say "look Rust bad Debian doesn't like it".
This seems like a big issue if you want your code to be packaged by Debian, and it doesn't seem easy to resolve if you also want to use the modern packaging tools. I'm not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian's model (of cont
... show more
This doesn't seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I'm sure there are tons of others. I'm actually surprised this doesn't happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say "look Rust bad Debian doesn't like it".
This seems like a big issue if you want your code to be packaged by Debian, and it doesn't seem easy to resolve if you also want to use the modern packaging tools. I'm not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian's model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it'll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they'll likely all run fine on Debian).
I find that funny that, since this is rust, this is now an issue.
I have not dwelved in packaging in a long while, but I remember that this was already the case for C programs. You need to link against libfoo? It better work with the one the distribution ship with. What do you mean you have not tested all distributions? You better have some tests to catch those elusive ABI/API breakage. And then, you have to rely on user reported errors to figure out that there is an issue.
On one hand, the package maintainer tend to take full ownership and will investigate issues that look like integration issue themselves. On the other hand, your program is in a buggy or non-working state until that's sorted.
And the usual solutions are frown upon. Vendoring the dependencies or static linking? Are you crazy? You're not the one paying for bandwidth and storage. Which is a valid concern, but that just mean we reached a stalemate.
Which is now being broken by -
... show more
the common practice is to relax the dependencies
I found this a bit disturbing
I find that funny that, since this is rust, this is now an issue.
I have not dwelved in packaging in a long while, but I remember that this was already the case for C programs. You need to link against libfoo? It better work with the one the distribution ship with. What do you mean you have not tested all distributions? You better have some tests to catch those elusive ABI/API breakage. And then, you have to rely on user reported errors to figure out that there is an issue.
On one hand, the package maintainer tend to take full ownership and will investigate issues that look like integration issue themselves. On the other hand, your program is in a buggy or non-working state until that's sorted.
And the usual solutions are frown upon. Vendoring the dependencies or static linking? Are you crazy? You're not the one paying for bandwidth and storage. Which is a valid concern, but that just mean we reached a stalemate.
Which is now being broken by - slower moving C/C++ projects (though the newer C++ standards did some waves a few years back) which means that even Debian is likely to have a "recent" enough version of your dependencies. - flatpack and the likes, which are vendoring everything and the kitchen sink - newer languages that static link by default (and some distributions being OK with it)
In other words, we never figured out a proper solution for C projects that will link with a different minor than the one the developer tested.
Well, /rant I guess. The point I'm raising does not seem to be the only one, and maybe far from the main one, for which bcachefs-tools is now orphaned. But I've seen very dubious arguments to try and push back against rust adoption. I feel like people have forgotten where we came from. And while there is no reason to go back per say, any new language that integrate this deep into the system will face similar challenges.
Well, it's now an issue with Rust since Cargo makes it a pain in the ass to do. It's one of the big things that makes me very reluctant to write any sort of system tools in Rust despite being a big fan of the language itself.
Because it's Rust it's now "rust bad" but Debian and other distros have been fucky with dependency management for YEARS. That's why we're moving to flatpak and other containerised apps!
Once again, the wider Linux dev community is trying to openly kneecap the first attempt in decades to bring Linux and its ecosystem up to a vaguely modern standard.
TLDR Debian and the traditional Linux package management system is antiquated and insecure, but somehow this is the fault of one of the many programming languages that is designed around the sensible expectations of being able to manage your own dependencies.
Fairly recently, I saw an app that served the same purpose as Barrier or Input-leap, allowing you use one computer to control the keyboard and cursor of multiple. I'm fairly certain it was designed with GTK 4, or maybe 3, and it had Wayland support. I've had no luck getting input-leap working well on my devices, so if anyone knows what app this was (or any other options) I would really appreciate it.
Update: Despite searching for 15 minutes before posting, I found it seconds later, thanks to DDGs reddit bang. It is lan-mouse. Will leave this up in case this software comes in handy for others.
Despite searching for 15 minutes before posting, I found it seconds later, thanks to DDGs reddit bang. It is lan-mouse. Will leave this up in case this software comes in handy for others.
Lan-mouse looks great but keep in mind that thereβs no network encryption right now. There is a GitHub ticket open and the developer seems eager to add encryption. Itβs just worth understanding that all your keystrokes are going across the network unencrypted.
I'd love some suggestions. I have a 1440p 32:9 monitor that can act as separate displays, but since Synergy, input-leap, and the other software KVMs don't work on Wayland, I'm having a bad time :(
The team behind EmuDeck, a project that started off to provide easy emulation on Steam Deck / SteamOS have announced their own hardware with the Bazzite Linux powered EmuDeck Machines.
The 8600G is quite a leap ahead of the Steam Deck in terms of performance and architecture. But of course you can just take the steam deck with you and play on the go or in bed ;)
I like the idea of a plug-and-play emulation station in a retro-styled case, but that case design is copyright infringement territory. Emulation devices are on shaky enough legal ground as it is, we do not need to tempt fate
Well, there are already great emulators for nearly every console on Linux, all you need to do, is create a full screen app, that is controlled by controller, where you pick your games And the hardware, of course, but this is mostly of the shelf as well, I would say
OS wise this is ready to go, my main concern is that their emu deck project is written in a way that needs KDE to be fully functional. Hopefully this is just because is started out as a steam deck app and isn't inexperience.
The old frontends like Hyperspin and Launchbox were similar in that they were developed in such a way it really limited where those projects could go, as such the retro frontends for Linux have been pretty limited.
Be really cool to see them expand Emu deck into a standalone program, it's even cooler that we're seeing the intention of Ublue already allowing people to achieve their goals.
I just wish every programmer completed the rustlings game/tutorial. Doesn't take that long.
I didn't even fully complete it, and it made me a way better programmer, because it forces you to think RIGHT.
It may sound weird for people who haven't experienced it, but it's amazing when you get angry at the compiler and you realise... It is right, and you were doing something that could f*ck you up 2 months in the future.
And after a bit of practise, it starts wiring your brain differently, and now my Python code looks so much better and it's way more safe just because of those days playing around in rustlings.
So yeah, Rust is an amazing language for everything, but particularly for kernel development. Either Linux implements it, or it'll probably die in 30 years and get replaced with a modern Rust kernel.
It is a project! All games are, π , just follow the instructions from the README. You'll be solving Rust exercises on your preferred editor, and get some feedback from a terminal window. It's great.
Retargeted triple buffering to GNOME 48 instead of trying to upstream it in 47 at the last minute. Actually upstream wants it in 47 more than we do. But recent code reviews are both too numerous to resolve quickly and too destabilizing if implemented fully. So Iβm not going to do that so close to release. There are still no known bugs to worry about and the distro patch for 24.10 only needs to be supported until EOL in July 2025.
Use triple buffering if and when the previous frame is running late. This means the next frame will be dispatched on time instead of also starting late. It...
Xaver Hugl, one of the KDE devs, wrote a wonderful post explaining triple buffering. Maybe check this out.
TL;DR (In the context of KDE Plasma) With all those changes implemented in Plasma 6.1, triple buffering on Wayland - is only active if KWin predicts rendering to take longer than a refresh cycle - doesnβt add more latency than necessary even while triple buffering is active, at least as long as render time prediction is decent - works independently of what GPU you have
Triple buffering is only active if the GPU isn't keeping up with double buffering. So it will mainly only be active for lower powered devices, like older integrated GPUs.
Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.
The 5.0.0 release includes the following changes to the previous release 4.9.1: - Rewritten authentication mechanism - Add escape %T to show current tty for window - Add escape %O to show number of currently open windows - Use wcwdith() instead of UTF-8 hard-coded tables - New commands: - auth [on|off] Provides password protection - status [top|up|down|bottom] [left|right] The status window by default is in bottom-left corner. This command can move status messages to any corner of the screen. - truecolor [on|off] - multiinput Input to multiple windows at the same time - Removed commands: - time - debug - password - maxwin - nethack - Fixes: - Screen buffers ESC keypresses indefinitely - Crashes after passing through a zmodem transfer - Fix double -U issue
I have a lot of trouble with the window/pane management. Moving panes to a different window is rather difficult. The server>session>window>pane hierarchy also seems way too deep for my humble needs.
The fact that the active window syncs between sessions is also really odd. Why can't I look at different windows on different devices?
Digitala banker utnyttjas fΓΆr penningtvΓ€tt. Helt digitala banker som polisen och en rad andra myndigheter kallar neobanker i en rapport, lΓΆper enligt just polisen en betydande risk att utnyttjas fΓΆr penningtvΓ€tt.
The vkd3d team is proud to announce that release 1.13 of vkd3d, the Direct3D to Vulkan translation library, is now available. This release contains improvements that...
Maybe not, but doesn't really answer my question what this would be used for.
I'm not hating, just interested; my last knowledge was that if you wanted to play Direct3D 12 games, you'd need the proton fork. But I don't know many other things Direct3D is used for, so...
The ultimate goal of the WIneHQ team is to have their own fully DX12 implementation. The reason why vkd3d-proton exists is that Valve didn't want to wait for it to mature and AFAIK they did have differences in what should be included in vkd3d. Which is why they don't work on the same project.
Why do we ask for donations so often? Because itβs important! As KDE becomes more successful and an increasing number of people use our software, our costs grow as well: Web and server hostinβ¦
It's once per year, easily dismissed, and can be permanently disabled. Seems entirely reasonable for a piece of free software that someone would use everyday
I mean, at least I'm not paying $200* for the privilege of being advertised to... I'd like an option to disable it permanently in the popup but it seems mostly reasonable?
^* This is the first price I got for a Windows licence when I searched for it. I know you can probably get them cheaper, but that's the price they're advertising, so eh.^
People spend countless hours building the software you use for free. Now they need to buy actual hardware yo build and test that software and what? They have to pay with their own money besides all that time they spent already so that you can continue to use this for free?
You're not forced to pay anything, they're asking for small donations
Either i wasn't clear or you are replying to the wrong person, but i am in support of foss projects asking for donations in a reasonable manor such as this
I personally think once a year is not enough. Every 6 months might be better. Also people already spend a lot during December that they might not prioritize donating to KDE.
For those complaining.... Well I don't know what to say to them. Such a big complex software which is 100% free should be allowed to remind us that they need money.
Don't forget they said it's running as a daemon specifically so you can easily disable it if it triggers you so much.
People have put work into this, for free. And the moment they ask for support, you immediately bring the pitchforks out, over a singular pop-up you can permanently disable? That's just plain disrespectful, at the very least
Unfortunately, there has always been the issue that a not-insignificant percentage of users of FOSS software believe the FREE part means "free as in beer" and take umbrage when asked to contribute.
I've long been a proponent (and I know I'm in a minority) that has advocated for a shift in the marketing of FOSS applications from "donation based" to "value based". Meaning that the expectation is that if you enjoy the software, you pay an amount that you believe is commensurate to your use. This is voluntarily of course...if you can't pay, than please use it and enjoy it. But those who can pay, should pay...at least a little bit, to offset the costs for those who can't.
It's more or less that the wording of FOSS apps needs to change so that you are expected to contribute if you can.
Just my opinion. Like I said, I know I'm in the minority. Just not a fan of the percentage of users that has always existed that (falsely) think that asking for money for your project is somehow anathema to the Open Source ideal and whine whenever they're asked to contribute.
Maybe donate 50 cents for every hour you used the software and it was useful to you.
That would be 1000 β¬$ per year if you work with Linux full time.
Letβs see some commercial software:
Microsoft Office 365 is 70 $β¬ per year. Adobe Suite around 700 $β¬ per year. IntelliJ IDEA about 170 $β¬ per year. Affinity Suite is 170 $β¬ once. Reaper is 60 β¬$ for a discounted license. Full featured media player like Elmedia costs 20 $β¬. BBEdit costs 60.
The FOSS windows and Mac FTP client Cyberduck asks for a minimum 10 β¬$ donation. It wonβt prompt you for a donation if you bought a license. The Duck applications are all pretty nice.
While I absolutely agree with what you are trying to say and donate to kde myself already. The issue with a lot of comments like yours is that the examples you use are almost always commercial software that already only see's limited use. I get value out of non commerical use applications such as dolphin, kate, konsole, and kdeconnect. Finding examples of popular paid versions of those applications would go a long way in my opinion because it would be something that more people can relate to.
The problem I see with the examples you are giving are the same problems I see when someone uses those examples as reasons why they can't switch to linux in the first place. And that is the fact that while those programs are popular. They aren't used by the vast majority of people who don't have a work related need to use them. Half the people that claim it as an excuse probably don't actually use those programs as well.
Your examples such as Cyberduc, Elmedia, and BBBedit are your stronger examples. Again just my opinion.
I like that terminology. I use some very high quality, high visibility FOSS software and sometimes feel bad that I more frequently donate to smaller projects that bring me value by filling a specific want or need that no one else is working on.
The full saying is "Free as in Speech, not Free as in Beer"
Basically the "Free" in free means that it's free to do with as you please, modify, etc... But not free as in "here's a free product...like getting a free beer"
That's also confusing and it is not the full saying. The full saying is "free as in free speech, not free beer".
From the FSF website:
Free software is a matter of liberty, not price. Think of βfreeβ as in βfree speechβ, not as in βfree beerβ. Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software.
And its mere presence will ensure I don't give them any more money. The core concept of inserting any ad in an OS is not behavior I am willing to reward.
So, asking you to VOLUNTARILY donate IF YOU WANT to with a pop-up you can simply ignore and/or disable is advertising? I don't understand... I mean, they give you a product for free, full of good features and updated regularly, and the moment they ask you to donate, again, IF YOU WANT to, it's considered advertising...
Those assholes! They should make an OS for free!!! How dare they ask for support?!?!
No one forces you to support them, if it's so annoying just disable it. I wonder if makes you happy work for someone for free... Hope it will happen to you so you'll understand how bad it is :)
That's an interesting logic. You do realise that at least 50% of the groceries in your local store are likely to have been advertised somewhere. Guess you should stop buying groceries too..
You pretty clearly don't know what a call to action is, or an ad is, because "please give money" is very obviously a call to action, and many ads make no effort whatsoever to sell any product.
I'm not against the idea, but I do think it's a bit unfair. There are dozens of projects KDE relies on that never even get the chance to ask for donations this way, simply because they don't need a GUI.
I believe KDE should at least offer to share the donations with other projects, projects that would otherwise have no voice. Something like the old Humble Bundle donation method would work really well, and let users to choose how their money is allocated.
While I understand where you are coming from. That goes for a lot of projects in general. Not to mention that KDE is literally an example of the thing you are talking about. KDE has an entire ecosystem of libraries that anyone can use called kde frameworks with many examples of these libraries being used on various projects large and small outside of KDE. They don't see a dime from this either. I recall a conference on TechHut's youtube channel spotting KDE's frameworks in the wild being used by companies at the event.
What are you talking about? Microsoft is charging for HEIF, HEIC, and looking to do it with AV1 and AVIF. Intel started development of EFI in the titanium days as a new standard for servers running unix before it became an open standard. Microsoft wasn't the only one involved in the standard but apple, redhat, hp, Intel, amd, and a laundry list of hardware/software manufacturers.
Most all the innovation happens in enterprise space with servers running unix/Linux. User operating systems are an afterthought when these features are initially conceived.
Honestly didn't realise till you pointed that out. I'm so used to seeing it that it doesn't register to me what it's saying anymore. Probably for the best that KDE only does it once a year; if it were daily I'm sure it wouldn't even register to people that it's asking for donations.
While I was still on Windows, the killer feature that kept WinRar installed, instead of only using 7zip, was the simple fact that its file explorer supported hotkeys like Ctrl+C, and that you could seamlessly copy files to and from Windows' file explorer.
FOSS in general needs better means of financial support. While the software is free and libre, developer time is not, and ultimately they gotta eat and pay bills. I hope they get positive results and don't catch much unnecessary flak.
basdiljhs
in reply to ArcticDagger • • •ArcticDagger
in reply to basdiljhs • • •AI generates covertly racist decisions about people based on their dialect - Nature
Naturelike this
Benign likes this.
basdiljhs
in reply to ArcticDagger • • •Cant believe I missed it was open access πππ
mods_mum
in reply to ArcticDagger • • •davidgro
in reply to mods_mum • • •like this
Benign likes this.
slazer2au
in reply to mods_mum • • •like this
Benign likes this.
Steve
in reply to slazer2au • • •Ready! Player 31
in reply to slazer2au • • •brezel
in reply to ArcticDagger • • •like this
OfCourseNot likes this.
Paradachshund
in reply to brezel • • •brezel
in reply to Paradachshund • • •Not_mikey
in reply to ArcticDagger • • •Everyone saying llms are bad or just somehow inherently racist are missing the point of this. LLMs for all there flaws do show a reflection of language and how it's used. It wouldnt be saying black people are dumb if it wasn't statistically the most likely thing for a person to say on the internet. In this sense they are very useful tools to understand the implicit biases of society.
The example given is good in that it's probably also how an average person would respond to the given prompts. Your average person who is implicitly racist when asked "the black man is" would probably understand they can't say violent or dumb, but if you rephrase it to people who sound black then you will probably get them to reveal more of their biases. If your able to get around a person's superego you can get a sense of their true biases, it's just easier to get around LLMs "superego" of no-no words and fine tuning counter biases with things like hacking and prompt engineering. The id underneath is the same racist drive to dominate that is currently fueling the maga / fascist movement.