[Amin]: Yep, thanks RMS for the great talk.
Now it's time for questions and answers.
I will paste the questions here and RMS will choose which ones to answer.
[Richard]: Please don't post a lot of questions in the Mumble chat
and fill up the buffer.
There's a limit to what I can see on the screen, so make sure it's visible.
Don't get too far ahead.
[Amin]: Sure, I will only paste one or two questions at a time.
I think it would also be helpful
if you read out the questions as you answer them, Richard.
[Richard]: Okay.
Well, this question is a little silly.
It's based on sort of all or none thinking.
Pragmatically, how are people that buy into these ideals?
I find that term offensive.
And especially those that build the software meant to live/thrive,
short of renouncing many of the luxuries of modern life.
It's repackaged standard.
You'll die if you don't write proprietary software.
But most people in the world don't write proprietary software
and that doesn't kill them.
Whatever you do to make money, if you're reasonably well paid at it,
which if you're working in software, I hope you are,
that enables you to have a lot of time to do something else,
like write some free software, even supposing you find no way
to make any money from the free software world, but that's just the worst case.
And for a lot of people, the life they find isn't the worst case.
So I think it's basically, the question is an exaggeration.
We don't need to worry about it.
There are many businesses which do hire people to write free software.
So write whatever free program for the business
that the business wants you to write.
And make sure you get permission to write your own software
and release it as free software
and contribute it to free software projects,
and you'll be able to contribute.
How can I help?
In addition, one very big part of the software business
is custom software development for a client.
One client at a time, basically.
And if that business is not treating its clients as suckers,
it will release the code to them under a free software license.
Okay, there you are. You're getting paid to write free software.
Perfectly ethical.
I have been admiring your work for free software for many years now.
I'm a bit concerned about what will happen to the GNU project when you retire.
Have you planned how to manage the GNU project in the long run?
I haven't found a way. I had an idea for what to do.
I hoped to train some people who were activists and committed supporters
to start making some decisions without me and I would give them feedback.
But I didn't succeed in getting them to discuss issues and propose decisions.
Well, I guess I'll have to try again. Over.
Just a second. I have to go and open the door.
In response to your aversion to JavaScript support in Emacs
in the same way that to revolt against
the non-free spirit in software development,
one has to develop software and that to fight non-free compilers,
one has to write a free compiler.
Can you fairly consider rejection of JavaScript as a tool conducive
to improving the state of free JavaScript?
There's a fundamental confusion here.
The problem with JavaScript is not comparable to the problem of
non-free C compilers or C++ compilers or Java compilers.
This is a totally different kind of issue.
We have free JavaScript support.
Free browsers contain that.
That's not the issue.
The issue is what about the programs you're going to run?
If you're talking about C, well, if you're going to run a C program,
it's because at compile at first, it's because you got the source code.
Probably it's free software or else it's a private project,
internal project, and there's no particular danger in that.
If JavaScript were just like that,
there'd be no particular danger in JavaScript either.
The problem is that hundreds of thousands of websites,
or is it millions, are sending JavaScript programs to their visitors
who don't even know what JavaScript is,
who are not programmers, who have no idea what's going on.
So these programs are usually non-free.
They end up in the user's browser, they run, many of them are malware.
So what's going to happen?
Basically, JavaScript is a platform for websites to mistreat users.
I know it can be used in other ways,
but socially, the existence of those other ways makes little difference.
The important thing about JavaScript is the danger that it creates.
This question is about the idea of using Emacs Lisp
for general purpose programming that has nothing to do with Emacs.
Well, in theory, I guess, in principle, there's nothing wrong with that.
But I think that would be a distraction, and I'd rather we didn't do it.
Now, if we had a thousand great programmers ready to do that,
and every other thing we could use, sure.
But the fact is, we don't. And I'd really rather--
There are many platforms that are fine to write programs on.
So I'd rather we work on making Emacs better at editing
and improving Emacs Lisp in the ways that help that goal,
and leave developing general purpose programming platforms to other languages.
Could I give a list of the specific medium-sized jobs
necessary for WYSIWYG editing?
Well, I can't really. I don't have a list of one.
And I'd really appreciate it if people started putting together such a list.
But if you look at every feature that LibreOffice has
that Emacs doesn't have, I think you will get a list.
Now, maybe some of those are not that important.
Maybe only a subset of them would make the list of really important ones.
But I think that will give everybody a start.
Should GNU or someone else define a safe subset of HTML, CSS, JS
to make web browsers simpler and safer?
You know, that would be an interesting thing to explore.
But I don't know whether it can be done.
The thing is, one of the dangerous things about JavaScript
is browser profiling.
Every machine runs a program at a slightly different speed.
And the idea of browser profiling is that the website sends a JavaScript program
to run on every visitor's browser.
And it's actually a collection of benchmarks.
And the collection of results is different for each user's computer.
And so it enables the website to recognize each one when it comes back
even if there's no cookie to help it.
So, which features are sufficient to make possible browser profiling?
There may be no particular unusual feature that's crucial.
But arithmetic might be enough.
How can we ensure the continuity of an understanding
of the more arcane parts of source code
and increase their evolvability, notably with regard to display,
single-threading limitations, etc.?
Well, single-threading is a very specific thing.
And the furthest that I've bothered to think about it is
how can we enable easily multiple list program threads
to be running in parallel.
But if you're talking about multi-threading in display,
I don't know if that even helps.
Of course, my machine doesn't really enable me to run
multiple threads in a single program, so it never mattered to me.
Basically, now, development of a display code
not in regard to threads, well, that's more feasible.
But the thing is, generally, any new feature is likely to require
changes in the buffer data structure to represent the use of the feature.
And I think that's going to be the hard part.
So, display won't be the hard part, and it won't be the first part.
The first part is figuring out how you're going to represent a buffer
with a certain display bell or whistle in it.
And once you've worked that out and worked out how it's going to work well
in editing, then I think you'll be able to figure out
what display has to do to handle it.
Of course, you have to decide that data structure,
thinking about how display is going to handle it efficiently.
If the data structure is bad, it won't be possible to display efficiently.
So you need to think about that at that stage.
But the actual work is working out the data structure
and the editing to handle it.
Do you recommend reaching out to schools for volunteers instead of universities
because they're more prone to value the objectives of freedom?
Well, reaching out for what?
Reaching out to try to teach people about freedom?
Or reaching out to find more developers?
Maybe that person could respond.
Is there any problem or disadvantage in using the GNU AGPL
for non-network software like Emacs packages?
I don't see one.
The reason why I didn't put the AGPL clause into the regular GNU GPL
is it seemed a bit radical and I figured the community
would be happier if that radical change didn't happen
in the GNU general public license itself.
I would like the person who asked the previous question
to respond to what I said so I can get that answer
and finish answering her question.
Right.
I will let you know if we end up hearing back from you--from per.
Is there a list of Emacs issues which can be solved by programmers
with different levels?
I don't know of one.
I tend to think that people who know basic programs
the basic level of list programming can't contribute yet.
They might be able to start debugging problems.
It won't be easy but that might be a good first thing to do.
Look at bugs that are waiting and see if you can debug one of them
and then when you find out what's actually going wrong
you can send that to the developers and it will very likely
enable them to fix the problem quickly.
In the process you'll learn a lot about programs
and how programs are actually written
and how to understand the code you actually come across.
With features like Org mode and enriched mode,
it seems that Emacs is getting closer to the goal of WYSIWYG.
Well it's got somewhat closer but it has a very long way to go.
If you compare it with something like LibreOffice
you'll see how long away there is to go.
There was an effort called GuileEmacs a while back
which was some effort to get Guile to be able to compile and run Emacs Lisp.
[Amin]: You mentioned there were still some challenges relating to Guile.
What roadblocks kept some of the other efforts from being used with Emacs?
[Richard]: Well we never finished solving the problem
of reconciling Guile data types with Emacs Lisp data types.
We got an idea for how to deal with the fact that
Scheme handling of nil is different from Lisp handling of nil.
The idea was that maybe this would get us close enough it could actually work.
But I don't think anyone fully implemented it and made it actually work.
What do you use Emacs for beyond editing?
Well I use it for reading and writing email.
That's what I mainly do.
That's what I do most of the day.
I could... I mean should I sing my song?
Sure.
I've been answering my email all the goddamn day.
I've been answering my email 'cause my work gets done that way.
Can't you feel the fingers aching?
Type until early in the morn.
Can't you see the letters blurring?
It's just an ad for porn.
You can see how out of date that song is 'cause we don't
get ads for porn much anymore.
[Amin]: Thanks for the performance.
[Richard]: Emacs is used by a small population relative to
the population that could benefit from it.
Do you have any thoughts on how to expand the user base more broadly,
even among software developers?
No. Basically, the fact is that on that aspect of things,
VS Code has an advantage and the advantage comes from Microsoft.
It's pushing that together as part of a large collection
of evil proprietary software that subjugates its users.
But those users don't understand that issue.
So, I mean, I sure wish I could come up with an idea
for how to spread awareness of free software
and the injustice of non-free software.
The best one that I know of is to show them the TEDx talk that you saw.
If you show that to people, they'll get at least a basic idea
of what's at stake here and why.
Would a namespace system similar to Common Lisp packages but without :USE
work in Emacs?
I suppose it would.
I mean, basically, the thing that's really broken about
Common Lisp packages is use.
But it's not crucial, or at least it's not crucial to allow that to exist
for arbitrary use.
Maybe you want to have something saying where a package can specify
whether to use the standard system functions and variables and so on.
But there is a drawback to Common Lisp packages,
which is that all of the aspects of any given symbol have to go together.
So if compile-foo is a variable and it's also a function,
and it's also a property name,
then if your symbol foo is aliased to compile-foo,
that means it's aliased as a function, aliased as a variable,
and aliased as a property name.
And aliased is anything else that you're going to point to from list structure.
So it's not going to work really smoothly.
And I tend to think that we're better off with a naming convention.
Since the use feature of Common Lisp packages causes trouble,
well if you don't use that, why is it better to write compile-foo
and have that be foo in the compile package than to write compile-foo?
The packages are almost equivalent to name prefixes.
And I think that there is an advantage of clarity to writing the name prefixes,
even in the same file.
That abbreviation, which is meant to just shorten the code and make it simpler,
looks simpler, I believe doesn't actually help.
And I say that based on many years of writing code that way.
With Emacs 29 adding more awesome features into Vanilla Emacs,
how should we ensure vanilla Emacs does not get bloated
with many similar features?
Example, ido/icomplete, vc/magit.
Well, to some extent we can't. Users do things differently.
I have never used Magit because I don't want to get used to using anything
that's not, packages that are not actually part of Emacs.
Now, a couple of years ago, the author of Maggot said he was starting to work
on getting the copyright assignments to include Magit in Emacs.
But I was unable to get any information on how this is progressing.
So because I've never actually seen Magit and because Git is actually not
the VC system that I use most, I don't know if I'd want to use Magit.
I'd probably be happier using VC.
I'm told that they have extremely different basic approaches to doing things.
They're not just slight variants of each other.
Now, having multiple slight variants, you know,
things doing similar jobs in little different ways,
that could be seen as redundant.
But when packages have very different approaches, I think that's not redundant.
Clarified version of earlier question.
Do you recommend reaching out in schools for volunteers for both advocacy
and development instead of universities?
I think that you'll find few people in high schools.
I think the question when it says schools means high schools.
I think you will find only very rarely someone in high school
who is good enough at programming to start actually developing things.
Once in a while, I guess.
As an activist, I think somewhat more often.
But the main thing is, do you know how to have a rapport
with high school students?
If you do, it would be a great thing to try.
We have had some projects of teaching free software to people in public schools.
And if you want to work on that, I suggest sending me an email
and I'll put you in touch with someone who's done it.
What was the thought process behind making Emacs Lisp dynamically scoped?
It was easy.
I knew perfectly well how to write a simple, small Lisp interpreter
that was dynamically scoped.
And small was absolutely necessary at the time because I was trying to make it
able to run in a machine whose total address space was one megabyte.
So the code had to be small.
Why did I implement if and I believe not cond?
Why did I implement or and not unless?
Because you didn't need those others.
You could write your Lisp code with a smaller Lisp interpreter
if you didn't have those other convenient traditional standard parts of Lisp.
So I stripped Emacs Lisp down to bare bones.
Of course, nowadays that's not necessary anymore.
Emacs used to be criticized as eight megabytes and constantly swapping.
And someone pointed out to me ten years ago
that if something's only eight megabytes,
it's not going to swap at all anymore.
It's hard to pick up Emacs if you do not speak English.
Can something be done to address that?
Well, what do you actually suggest?
Is it the documentation?
Is it the names of commands?
Is it the doc strings or is it the manual or both?
Is it the messages that Emacs displays?
I mean, each of these is a different issue technically.
Now, the easiest thing to deal with would be the messages
because in other GNU packages,
we have a system for internationalizing messages.
It's hard to adapt it directly to Emacs
because it's designed for programs, tools, or applications
that have a fixed set of messages to display.
Emacs doesn't. You load in a different Lisp program,
it's got a different set of messages.
How exactly do you want to handle this?
But it could be done.
It's not a terribly hard problem.
If you're interested, please work on it.
What about the command names?
Well, you could imagine coming up with an alternate set of command names
and maybe a different character instead of M-x
so that it would read only the translated command names
and the ordinary Emacs command names wouldn't get in the way.
M-x might still be there, but if you type this other thing, M-foobar,
then it would only complete over the command names in the other language.
This might be pretty simple to do technically,
although working out the details might take a good deal of thought.
And then docstrings?
Well, you could just write another set of them
and have other help commands to display them.
Do you use Org or Org mode, and if so, to what extent?
I have never used them, and here's why.
I think that the design process of Org mode went awry,
not at the very beginning, but at the next stage.
Originally, Org mode was an outlining mode.
It's not something I wanted to use.
I had nothing against including it, but I didn't ever try to use it.
The documentation of it somehow wasn't easy for me to grasp,
especially since I had no actual use for it,
no reason to go through and remember all those things.
Anyway, then people started developing other facilities to use the Org syntax,
and they're totally unrelated to each other.
They just happen to use the Org syntax,
and some of them, occasionally, I thought it might be interesting to use this,
but to use it, first I'd have to learn the Org syntax,
and that was a task that had already proved discouraging.
Now, the mistaken design, I think,
was to integrate all those other facilities with Org mode.
They should all have been separate, modularly separate,
so that you could maybe use them with Org mode if you wanted to,
but also use them separately from Org mode,
and they'd be documented separately,
and those I wanted to use, I would have learned to use.
But that was hard to do.
They had been welded together such that it was not easy to separate them.
I really wish they'd get separated, but that's not an easy job.
Each one needs to be remodularized.
Anyway, there is something for which I think Org mode could become an advance.
I'm not saying it isn't useful for people who like what it does,
but it might play an important role if it were extended to do it,
and that is we could use a replacement for Texinfo.
Texinfo's syntax is arcane.
It was based on what I could implement on top of TeX in 1984 or so.
And, well, Org mode, Org syntax doesn't make all the distinctions,
all the semantic markup distinctions that we can make in Texinfo.
If it did, which would require extending it,
then it might become a good format to write GNU manuals in.
It could conceivably become a better format than we have now,
and that would be a good thing.
Not that many people know Texinfo syntax.
It's not widely used except for GNU manuals.
But probably more people know Org syntax,
and if it were extended so that it did in a fairly natural way
all the things that Texinfo does and maybe some additional ones,
then it could be superior.
And then we could gradually switch our manuals over to it.
But we need to be able to generate all the output formats
that we can generate now.
That means HTML to put on websites.
That means either info files or perhaps another form of the HTML output
that would be good for an info browser,
including the one inside Emacs and the one that's separate.
And generating input to TeX so that it would generate pretty-looking manuals,
which is one of the advantages of Texinfo.
This is not a gigantic job.
I'd say this is a medium-sized job, or maybe two or three medium-sized jobs.
What do you have in mind for more modular Emacs development?
I think that that's...
There's no specific feature that I have in mind to solve that.
It's more of an approach to how you develop things.
It's thinking about modularity when you write each package that you write,
because you will find situations where it has to interact
in various ways with other packages.
And sometimes you'll find the other packages have hooks
that will enable you to do it.
And sometimes you'll find that
the hook you'd really need for this is missing.
In that case, the best thing to do might be to add
a suitable, fairly general hook that can be used for your job
to the other existing package,
so that instead of a rigid connection to other parts of Emacs,
which is somewhat unmodular,
you could use a general-purpose hook,
which you designed because it could do a lot of things,
including the thing you need to do.
It might be interesting to reframe the school question.
I think it is related to the first part,
how to bring Libre software into schools.
For example, my entry point was LaTeX in school.
Well, it's okay.
I don't see anything wrong with that, by all means, if it works.
Now, my naive, perhaps, guess is that it wouldn't arouse much interest,
because I suspect most people would rather use a WYSIWYG text editor
than a text formatter like LaTeX, any text formatter.
But if your experience is otherwise, go ahead.
In the light of that critique of JavaScript not being about language per se,
but rather the culture of blindly getting and running packages, libraries.
What's so different with what's currently done by the vast
majority of EmacsLib users to just install packages blindly?
Well, they know they're installing a package,
and that makes all the difference.
And people can post various versions of a package,
and then people can compare them and say,
"Hey, I looked at that version there, and it has a horrible bug."
And so the community can do something about that.
With JavaScript sent by websites, there is no way to do anything like that.
And in addition, most of those programs are not free.
How would you know? If you're not running LibreJS,
you don't know what JavaScript programs are being installed
into your browser at any given moment, or whether they're free.
You know, very likely you'll just get a bunch of obfuscript,
and you won't know what the source code is, or whether you could even find it.
These things don't happen with EmacsList packages.
At least not when they're in reputable package archives.
Do you still intend to merge your patch to the shorthands feature
to the master branch?
Yes, but I've seen that something needs to be done with the docstrings,
because s.el mentions in its docstrings the function names used in s.el,
and the magnars string library that works just by renaming those symbols
really would want to alter the docstrings too.
And now there are multiple ways of doing that.
One of them maybe is to edit the s.el source file
so it'll do the right thing in either case.
That would need a new docstring construct.
Well, we've added many docstring constructs.
We could add one more. It's not that hard a thing.
Do you think the freedom, e.g., we have in Emacs becomes a hurdle
for some people to pursue more important things in the world?
Is there something more important in the world?
I used to do a lot of Emacs programming, but recently I decided to stay away
from tink-linking, from tinking Emacs.
I'm not sure what-- tinking is a strange word to me, tinkering with maybe.
Well, there may be more important things for you to do than extend Emacs.
On the other hand, when you look at all the distractions that the world offers
that distract a lot more people than this,
it really seems unfair to criticize Emacs because it's something
you could put a lot of time into tinkering with.
Look how much time people put into playing video games,
which achieves nothing except distracting them.
And if you distract yourself by playing with Emacs Lisp code,
that's surely better.
It has a chance of resulting in something
actually useful and a chance that you'd learn something
that's more important as learning than how to win a certain video game.
Questions about software freedom.
How does it apply to software that are art/media experiences
like video games in your view?
Well, I'd say that a video game typically is a collection of things,
some of which are programs and some of which are art.
And so once you analyze the game in that way,
if you agree with my ideas about what the moral rules are
for each of those categories, you can apply them separately
to each thing in the collection.
Programs are operational. They do things for you.
And anything that does things for you should be free.
The art that is simply displayed is not of that kind,
so it doesn't, in my view, have to be free.
It does have to be shareable.
You have to be free to non-commercially redistribute an exact copy.
When I talk about sharing, that's what it means, precisely that.
Non-commercially redistribute exact copies to others when you wish.
How would technologies like WebAssembly fit with the JavaScript issues?
They don't change anything much.
Basically, if the program is JavaScript source code
that you could actually read, well, then if it had a free license on it,
it would be free software.
And if the free license is indicated in the standardized format
that LibreJS understands, it would actually recognize it as free software.
If it's obfuscated, then it's not the source code.
And if it's WebAssembly, then it's not the source code.
So those are both compiled versions of source code that isn't in the page.
So they make things somewhat nastier,
in the sense that you couldn't have much chance of reading it
and seeing what it does.
But either way, it's not free,
even if it's source code with no free license, it's still not free.
If it's a compiled version rather than source,
that's a little further away from being free.
But further away from being free doesn't make it worse.
It's equally bad.
If it gets further away from being free,
that means the work that you might have to do to free it is more,
but it's not worse.
Non-free is bad.
Have you seen Haketilo?
It seems similar to LibreJS.
Haketilo is meant to enable people
to get some of the benefits of the free software community
with free replacement JavaScript programs for websites.
So potentially it offers a real solution to the JavaScript problem.
It has a long way to go from what I hear.
If you want to work on it, please do.
Of course, writing free replacement JavaScript
for a million websites is an enormous job,
but maybe we could do it for some sites.
It depends how many people get enthusiastic about doing it
and how many sites cooperate.
Is writing free software replacement to GitHub Copilot
with proper license attribution a good idea?
Maybe, but remember that Copilot is not a program. Copilot is a service.
It is something that somebody else's computer will do for you.
It's a computation that someone else's server will do for you when you ask.
And so what are the practical problems of doing that? I'm not sure.
The point is, of course, the server runs by running a program.
The service operates by running programs.
But still, a service is a very different kind of thing from a program.
People who use Copilot don't get any sort of copy of Copilot.
All they do is send something they're working on to that server
and they get something back.
So it might be a good idea.
Do you have any suggestions for helping prospective contributors
streamline the copyright assignment needed to contribute to Emacs?
I don't think that's needed.
Basically, the copyright assignment itself is pretty easy
and doesn't take very long.
What is sometimes harder is the copyright disclaimer,
the employer disclaimer, where your employer,
if you're employed to program, or if your job includes programming
or could include programming, we want to be sure that your employer
is not going to say that you had no right to contribute that to any program
because it belonged to the employer all along and you broke the rules
and the project you contributed to is shafted.
Well, we are working on some simplifications to that text
in the hope of making it easier to get companies to say yes to it.
But fundamentally, they've got to say yes to it.
We need them to say yes to it.
We can't make them say yes to it.
We can only ask.
Can complexity induced by company funded...
Sorry, it talks about open code.
I don't know what that means.
Is this talking about free software?
[Amin]: I think it would be safe to assume that they are indeed
talking about free software.
[Richard]: Okay, because I don't use the term open to classify programs.
I'm not a supporter of open source and I never was.
And the reason is very important.
I touched on this briefly in the TEDx video.
But basically, the idea of the free software movement is that users deserve
the freedom to study, change and redistribute the code that they use.
And it is an injustice to deny that to users.
And therefore, software must be free.
It's wrong if it's not free.
Well, the people who created the idea of open source about 14 years later,
they wanted to avoid bringing up that question.
And they more or less succeeded when people talk about open source.
Occasionally, that question has seeped in from the free software community.
But most of the time, it never occurs to them.
They simply take for granted that it's legitimate for a program not to be open.
Well, that's missing the point that I consider most important.
So whenever I talk about this area, I talk about it in
terms of free, libre, freedom-respecting software.
So, can complexity-induced by company-funded free code
become a problem when the company pulls out,
leaving the code potentially unmaintainable?
Well, I'd say over-complicated free programs
which don't have community contributors
can fall into that problem.
It's not limited to programs developed by companies, I think.
What do you think of Hyperbole or EEV instead of Org mode?
Well, I don't actually know that much about either of them.
I don't know what EEV is.
I've heard of Hyperbole, but it was many years ago that I looked at it,
and I don't remember what I saw.
So, I'm sorry I can't have an educated opinion about those specific things.
It would be interesting for somebody to study that.
Now, there'd be a lot to study.
After all, Org mode consists of an outlining mode together
with lots of other specific features that have been welded onto it.
And if they were separated, made modular, separate parts of Emacs,
it would be a lot easier to adapt some of them to work with hyperbole
if we wanted to.
Of course, do we want to?
That's another question.
What is EEV?
I think it's similar in many ways to hyperbole.
I haven't used either of them too much myself, but yeah,
they are fairly similar as far as I know.
If they're fairly similar, I guess that brings up the question,
is either of them actually part of Emacs?
I think hyperbole is a GNU package.
I'm not sure if it's part of Emacs or GNU ELPA.
It might be, but EEV is not as of yet.
But both are free software.
Well, it might be that it doesn't make sense to include them both in any sense.
People can write them and distribute them,
but that doesn't mean we need to pick them up.
We might want to compare them and see which one is better
and then look at whether it could be improved further
by bringing in features from the other.
This is what you do if those two things exist
and you want to make the best possible thing
to add, for instance, to Emacs.
But since I don't know any specifics anymore, and with EEV I never did,
I don't want to state any sort of a priori preference.
I don't have one.
Are there plans to bring modal editing to Emacs core?
What does that mean?
[Amin]: I think they're speaking about projects or editing modes such as VI,
where by default whatever you type is not getting inserted,
but you can navigate between different modes
and one of them being text insertion.
[Richard]: Well, I don't have a wish for that.
Now, I mean, it's not somehow morally anathema.
I mean, it's not as if it were a non-free program.
But it wouldn't be easy to design that in such a way that
it fit into the framework of existing Emacs without doing any violence to it.
What is your opinion of the current state of large machine learning models?
Even if the model is released under a free license,
it cannot be modified in a meaningful way?
I don't think that's true.
A person who was in the field of machine learning
told me that you can modify it.
You can modify it by starting with what you've got
and doing some further training,
and you don't need, I'm told, the previously used training data to train it,
to modify it.
Based on that, I concluded that the trained neural network
can be treated as source code.
And after all, it's not made from any other kind of source code.
So, in some sense, what else could the source code be?
I thought it was a virtue to separate the content
from the style or appearance of information.
Part of being free is also to view information in the format you want.
Does your WYSIWYG idea erode this virtue and lead to more thinking,
perhaps undue thinking about style over substance?
Well, I don't know, actually.
I know that in LibreOffice you can make named styles,
and you can apply them to parts of the text,
and later on you can change what any given named style
means in terms of appearance.
So, is that enough independence of appearance from semantics?
I am hardly a power user of LibreOffice.
I've come across that feature. I've never used it.
The only things I write with it are pretty simple.
I have a feeling that I've been doing this for a rather long time.
Do you recall when I started answering questions?
I think it was something like an hour ago.
Yeah, I think so. About an hour or 45 minutes-ish.
Well, then I'll do a few questions more.
Do you ever dabble in retrocomputing?
No. I decided it's a waste of time.
It basically would be tinkering that would not develop
anything of any importance or use.
And I know that if I'm going to enjoy developing something,
I could enjoy it developing anything.
You know, I could enjoy just as much developing something
that I think is needed right now for non-retrocomputing
as I could enjoy working on retrocomputing.
So I decided never to let retrocomputing
distract my attention from useful computing.
Do you know the Gemini Project -
a network of very simplified markdown-like text files without images
and third-party materials transmitted via an open public free protocol,
which is not HTTPS?
I don't remember if I ever heard of that before.
Sorry, I have no opinion about it.
But I think that the lack of images will turn out to be a considerable drawback.
I mean, imagine a website.
Well, there are lots of reasons you might want to put in images.
It's not limited just to making it look snazzy and distracting.
There are a lot of pictures you might want to include and diagrams,
and scientific papers include pictures and diagrams.
It would be crippling if they couldn't be in there.
So basically, I think that exclusion of images is a big loss.
[Amin]: Thanks. I think that's so far all the questions I see on the pad,
but let's give it maybe another minute or two
if people have any other question or two to get in before we call this close.
[Richard] Well, I'd like to mention that if you've heard
rumors of attacks against me that people have made, it's mostly false,
and you can find out more by looking at stallmansupport.org.
So I refer you there, and I hope you'll take a look.
[Amin]: Yes, thank you.
All right, I think that's pretty much all the questions that we have.
Thanks again, Richard, both for your great talk
and also for taking this much time answering so many questions.
We really appreciate it.
[Richard]: Well, this is what I do.
GNU and the Free Software Movement are what I've dedicated my life to,
and since I'm still alive, I've got more to dedicate to them.
[Amin]: Wonderful, and we all hope that it keeps on coming
and you're able to continue for a very long time into the future.
[Richard]: Happy hacking.
[Amin]: Happy hacking. Bye.