remove obsolete pages. they will me 301 redirected in nginx
parent
03368d08e7
commit
64974ededf
|
@ -21,8 +21,6 @@ rms.ru.md
|
||||||
rms.tr.md
|
rms.tr.md
|
||||||
rms.vi.md
|
rms.vi.md
|
||||||
rms.zh.md
|
rms.zh.md
|
||||||
resignations.md
|
|
||||||
libreboot202104xx.md
|
|
||||||
libreboot20160907.md
|
libreboot20160907.md
|
||||||
libreboot20160902.md
|
libreboot20160902.md
|
||||||
libreboot20160818.md
|
libreboot20160818.md
|
||||||
|
|
|
@ -1,143 +0,0 @@
|
||||||
% New Libreboot release, ETA late April 2021 / early June 2021
|
|
||||||
% Leah Rowe
|
|
||||||
% 30 March 2021
|
|
||||||
|
|
||||||
Rapid progress is being made towards a new Libreboot release. It should be done
|
|
||||||
by late April or early June 2021. Many new boards will be supported, with lots
|
|
||||||
of bugs fixed, new features added and the latest coreboot/GRUB/SeaBIOS versions
|
|
||||||
used on all boards. The Libreboot website will be massively overhauled.
|
|
||||||
|
|
||||||
I, Leah Rowe, have re-taken full control of the Libreboot project after 4 years
|
|
||||||
delay in bringing out a new release. Long story short, Libreboot began a new
|
|
||||||
and ambitious re-write of its build system in 2017; as of 2021, that build
|
|
||||||
system is still not ready; the design is fundamentally flawed and the code is
|
|
||||||
unmaintainable so I have scrapped the rewrite entirely. The work will be
|
|
||||||
preserved, for reference, but it has otherwise been abandoned.
|
|
||||||
|
|
||||||
I, Leah Rowe, was not responsible for that re-write. The design of that
|
|
||||||
re-written build system is fundamentally flawed, and it has too many bugs. The
|
|
||||||
people working on it kept adding too many new features without fixing
|
|
||||||
fundamental issues. I have revoked all of their access to project
|
|
||||||
infrastructure; Libreboot is now lead by me. I have a completely different idea
|
|
||||||
for how to run the project and what a *coreboot distro* should be.
|
|
||||||
|
|
||||||
I, Leah Rowe, stepped down from Libreboot development in 2017. Since late 2020,
|
|
||||||
I've been actively developing Libreboot again. I have been working on another
|
|
||||||
project, forked via Libreboot 20160907 build system `lbmk` but on documentation
|
|
||||||
from December 2020. That project is: <http://osboot.org/> - if Libreboot seems
|
|
||||||
dead to you right now, it's because I've been doing the work exclusively in
|
|
||||||
osboot, with the intention of adapting that work back into Libreboot.
|
|
||||||
|
|
||||||
osboot has very different goals than Libreboot, but the build system there is
|
|
||||||
vastly improved. I have focused on adding all *libre-friendly* boards to osboot
|
|
||||||
which means anything that Libreboot does support, or can support. I am
|
|
||||||
presently using a version of coreboot from December 2020, with patches applied
|
|
||||||
on top to improve certain functionality on specific boards.
|
|
||||||
|
|
||||||
osboot *does not comply* with Libreboot policy; it permits binary blobs. The
|
|
||||||
purpose of osboot is to provide support for coreboot targets that aren't
|
|
||||||
yet easy to support in Libreboot, for those who wish to use such hardware. This
|
|
||||||
is because in many cases, such people will insist on using what hardware they
|
|
||||||
already have, or they have a need for newer hardware. The coreboot software has
|
|
||||||
support for lots of hardware. In my opinion, these people will likely not just
|
|
||||||
install upstream coreboot with a payload; they will want something pre-built
|
|
||||||
for them that is easy to install, with user-friendly instructions and support.
|
|
||||||
In other words, they want a *coreboot distro* like Libreboot. In the name
|
|
||||||
of *harm reduction*, I provide the osboot project precisely for such people, so
|
|
||||||
as to reduce the amount of non-free software they use; the idea is that osboot
|
|
||||||
is better, for those people, than using a *completely* non-free machine. osboot
|
|
||||||
also contains support for most libreboot targets at this point, and the rest
|
|
||||||
will be added soon; on *those* (and all other x86 machines), microcode updates
|
|
||||||
are included by default. *Most* boards that coreboot supports do still require
|
|
||||||
binary blobs; the ones that Libreboot supports represent a small minority of
|
|
||||||
coreboot targets! This is a sad reality, which has limited the Libreboot
|
|
||||||
project's possibilities for years.
|
|
||||||
|
|
||||||
I wanted to start something like osboot for a long time. Well, I'm nearly done
|
|
||||||
adding all *libre-friendly* x86 boards to it; in addition to ones already in
|
|
||||||
Libreboot, I've added others such as the ThinkPad R500. More will be added
|
|
||||||
soon. I have made vast improvements to the build system (compared to Libreboot
|
|
||||||
20160907), so all I need to do now is add all the configs for those libre
|
|
||||||
friendly boards and ensure that adequate documentation is provided. I can then
|
|
||||||
provide a release with pre-compiled ROM images and full source code.
|
|
||||||
|
|
||||||
As soon as this is ready, I will *fork osboot* to create `osboot-libre`. This
|
|
||||||
will be FSF-endorseable and comply with the same criteria as Libreboot. The
|
|
||||||
reason is because I want to create a source-based, rolling release coreboot
|
|
||||||
distro with configurability similar to what you'd find in emerge and the
|
|
||||||
OpenWRT build system. However, that's for much later:
|
|
||||||
|
|
||||||
osboot-libre will be used as a reference to then create a new Libreboot release.
|
|
||||||
The *source-based coreboot distro* aspect will not be implemented in osboot or
|
|
||||||
osboot-libre until the new Libreboot release is ready.
|
|
||||||
|
|
||||||
Aside from specific board support, here are some nice improvements currently
|
|
||||||
in the osboot build system compared to Libreboot 20160907:
|
|
||||||
|
|
||||||
* Generally it is much more cleanly written, and more modular
|
|
||||||
* You no longer have to manually run individual commands within lbmk (in osboot
|
|
||||||
it's called osbmk. osboot-make): each command checks if previous commands
|
|
||||||
required were run, and runs them if not. **This means you can just type a
|
|
||||||
single command to build a ROM image if you wish!**
|
|
||||||
* Makefile included, making the build system even easier to use. The Makefile
|
|
||||||
contains no logic, it just runs osbmk (osboot-make) commands
|
|
||||||
* Vastly improved `grub.cfg`: un-hardcodes a lot of functionality, improved
|
|
||||||
usability on i945 targets such as X60/T60/macbook21, USB HDD support out of
|
|
||||||
the box
|
|
||||||
* GRUB module missing errors fixed; all standard GRUB modules now included
|
|
||||||
* LUKS2 now supported in the GRUB payload.
|
|
||||||
* Geli now supported in the GRUB payload. (FreeBSD encryption thing)
|
|
||||||
* The documentation is much cleaner
|
|
||||||
* Tianocore payload supported, for UEFI
|
|
||||||
* SeaBIOS now included as standard, on all ROM images; on images with the GRUB
|
|
||||||
payload, SeaBIOS is an option in the boot menu.
|
|
||||||
* The build system is *much* easier to use when adding new board configs
|
|
||||||
* Each `board.cfg` for each board defines what payloads it is to use, what
|
|
||||||
architecture, etc. Coreboot trees are now handled on a directory basis,
|
|
||||||
instead of creating multiple branches in a newly initialized Git repository;
|
|
||||||
this is less efficient on disk space, but it is simpler to maintain, so now
|
|
||||||
the priority is to minimize how ever many coreboot revisions are used.
|
|
||||||
* Boards can link to other boards; for example, X200 could use the same setup
|
|
||||||
as T400. However, in this case the specific board would still have it's own
|
|
||||||
specific coreboot configuration files.
|
|
||||||
* Build system highly optimized; unnecessary steps are skipped. If you just
|
|
||||||
want to build for 1 board, you can! Only the things necessary for that board
|
|
||||||
will be compiled by osbmk, at least automatically that is!
|
|
||||||
* In general, it is a *much more automated* automated build system!
|
|
||||||
|
|
||||||
Check the hardware support compared to Libreboot:
|
|
||||||
<https://osboot.org/docs/hardware/> (NOTE: some of the machines listed there
|
|
||||||
cannot be added to Librbeboot, but you can see that a lot of Libreboot-friendly
|
|
||||||
hardware is already present in osboot. Only those targets that can run blob
|
|
||||||
free will be in Libreboot, and coreboot supports of lot more of such hardware
|
|
||||||
nowadays).
|
|
||||||
|
|
||||||
Plans:
|
|
||||||
|
|
||||||
* Scrap libreboot.git
|
|
||||||
* Split build system into `lbmk.git`
|
|
||||||
* Split web/docs to into `lbwww.git`
|
|
||||||
* Split images into `lbwww-img`
|
|
||||||
* Split utils into separate repositories e.g. `ich9utils.git`
|
|
||||||
|
|
||||||
This splitting of the repositories will make each part of Libreboot much more
|
|
||||||
easily maintainable by contributors. This splitting up of the repository has
|
|
||||||
already been implemented in osboot!
|
|
||||||
|
|
||||||
**The entire `libreboot.org` website will be -->nuked<-- from orbit.**
|
|
||||||
|
|
||||||
Stay tuned! The new site and new project will be much better.
|
|
||||||
|
|
||||||
PS:
|
|
||||||
|
|
||||||
Code of Conduct abolished
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
Libreboot has abolished its Code of Conduct. I no longer believe that a CoC is
|
|
||||||
effective; in reality, it does not prevent bad behaviour and it discourages
|
|
||||||
people from joining the project. CoCs are ultimately counter-productive. It's
|
|
||||||
obvious when someone is behaving badly; common sense will prevail!
|
|
||||||
|
|
||||||
All I want is code. Your code.
|
|
||||||
|
|
||||||
Just try to behave yourself on IRC, OK?
|
|
|
@ -1,118 +0,0 @@
|
||||||
% swiftgeek and Andrew Robbins removed from the Libreboot project
|
|
||||||
% Leah Rowe
|
|
||||||
% 30 March 2021
|
|
||||||
|
|
||||||
Introduction
|
|
||||||
============
|
|
||||||
|
|
||||||
As the title suggests, Andrew Robbins and swiftgeek (Sebastian Grzywna) are no
|
|
||||||
longer a part of the Libreboot project. While I am sad to see them go, I say
|
|
||||||
one thing freely: I wish both of them well. I'm extremely grateful for the work
|
|
||||||
that they have done over the years; their passion, their burning desire to help
|
|
||||||
others and their energy for Free Software is inspiring. Swiftgeek in particular
|
|
||||||
has given me a lot of advice on things over the years. I *hope that they do*
|
|
||||||
continue their work, and I've already told swiftgeek that I will provide him
|
|
||||||
with the money/resources if he needs it, to help him set up physical hosting
|
|
||||||
infrastructure for a new project forked from Libreboot. I will do it without a
|
|
||||||
moment's hesitation.
|
|
||||||
|
|
||||||
I also told swiftgeek that I would be happy to continue working with him, if
|
|
||||||
he wished. So far I have not yet spoken to Andrew, but he learned of my recent
|
|
||||||
decisions and has now denounced me on his website; I am not angry with him for
|
|
||||||
this, in fact I would be angry if I were him. I will address his article later
|
|
||||||
in this post. Unfortunately, Andrew's article means that I do not wish to talk
|
|
||||||
to him anymore.
|
|
||||||
|
|
||||||
Their work that they did in Libreboot is now archived. It will be preserved, in
|
|
||||||
the Git repository, for historical purposes. If they wish to continue with the
|
|
||||||
development on their version of libreboot, they may do so; in fact, I would not
|
|
||||||
want to stop them! I merely disagreed on a lot of technical levels with the
|
|
||||||
way their *build system* (the Paper build system) was implemented. Their build
|
|
||||||
system is, as of today, an unfinished re-write of Libreboot that began in 2016
|
|
||||||
by PaulK when he was a Libreboot project member, then continued in 2017 by
|
|
||||||
Andrew Robbins under the guidance of swiftgeek.
|
|
||||||
|
|
||||||
On 28 March 2021, I decided that I was nonetheless unhappy with their progress;
|
|
||||||
they had failed to produce a release in the last few years, and my gut instinct
|
|
||||||
told me that they would not make a new release at all for at least another few
|
|
||||||
year. They would have kept being awesome, implementing all kinds of cool
|
|
||||||
whacky features but their *Paper build system* (which is what it's called, the
|
|
||||||
version they worked on) would have only got endlessly more complex. I did not
|
|
||||||
want their code in Libreboot anymore.
|
|
||||||
|
|
||||||
In [my last post earlier today](libreboot202104xx.md) I announced the
|
|
||||||
extensive amounts of work that I've done on coreboot and related software, in
|
|
||||||
preparation for a new Libreboot release; in that post, I described all of the
|
|
||||||
major improvements and what is left to be done for the next Libreboot release
|
|
||||||
ETA late April 2021 / early June 2021. I only started this work in early
|
|
||||||
December 2020; I scrapped the re-write (Paper build system) and continued where
|
|
||||||
I left off back in September 2016, continuing development
|
|
||||||
of *lbmk* (libreboot-make). lbmk is much simpler and easier to maintain than
|
|
||||||
Paper, and my argument to swiftgeek has always been that it could easily
|
|
||||||
implement all of the advanced features Paper has (Paper is badly designed,
|
|
||||||
but has nice features). I will indeed be doing this! For example: uboot
|
|
||||||
integration in Libreboot, for ARM devices.
|
|
||||||
|
|
||||||
In 5 months I've made a lot of progress; I am
|
|
||||||
mere *weeks* away from having a totally new Libreboot release ready.
|
|
||||||
Nothing has changed since that last post, in fact it's even still the same day,
|
|
||||||
and the above is merely a summary, but a development has happened:
|
|
||||||
|
|
||||||
Andrew's article
|
|
||||||
----------------
|
|
||||||
|
|
||||||
Andrew Robbins is rightly angry at me right now. I do not expect his
|
|
||||||
forgiveness ever, but I would like to address some of the points he has made in
|
|
||||||
an article about me. The article is here:
|
|
||||||
|
|
||||||
http://web.archive.org/web/20210330215036/https://www.andrewrobbins.info/libreboot.html
|
|
||||||
|
|
||||||
The only point I wish to address is:
|
|
||||||
|
|
||||||
Yes, I made an arrangement with Andrew to set up an LLC for himself in
|
|
||||||
USA (LLC = limited liability company). I told him that I would be shipping him
|
|
||||||
laptops that I buy from USA suppliers, then he would install libreboot on those
|
|
||||||
and ship them to my USA customer, and I would pay him 75% of the additional
|
|
||||||
profits generated (because it's sales I wouldn't otherwise get: the 25% would
|
|
||||||
cover my admin fees and overheads, while he gets the lion share of the profit).
|
|
||||||
|
|
||||||
In Andrew's article, he says that I was *stringing him along* so let me be
|
|
||||||
clear: although Andrew clearly no longer trusts me, I am still willing to do
|
|
||||||
this with him. I told him in the beginning that it had nothing to do with his
|
|
||||||
position in the Libreboot project; it just made good business sense, and it
|
|
||||||
still does. I would not reduce my workload by doing this with him: I would
|
|
||||||
keep my workload the same while giving *him* a workload for him to make his
|
|
||||||
own money.
|
|
||||||
|
|
||||||
Many months ago on IRC, I also proposed to swiftgeek that we start a repair
|
|
||||||
company. Similar to Louis Rossman's macbook repair company, but for Thinkpads;
|
|
||||||
swiftgeek has great knowledge of ThinkPad repair, and I could find him
|
|
||||||
customers.
|
|
||||||
|
|
||||||
I understand Andrew's anger, and fully expected it. I did not take the
|
|
||||||
decisions I made in Libreboot lightly; I made those decisions because I think
|
|
||||||
they were (are) the right decisions to make, for the good of the project.
|
|
||||||
|
|
||||||
When I bring that new release out, I will be re-opening the Libreboot
|
|
||||||
infrastructure for new outside contributors, including those who wish to have
|
|
||||||
review/push/pull access.
|
|
||||||
|
|
||||||
Needless to say, I reject Andrew's calls for me to hand over control of the
|
|
||||||
Libreboot project. I'm back, and I have great plans for the project. I intend
|
|
||||||
to implement them all, fully.
|
|
||||||
|
|
||||||
Closing remarks
|
|
||||||
---------------
|
|
||||||
|
|
||||||
I will say once again:
|
|
||||||
|
|
||||||
I wish swiftgeek and Andrew all the best, in whatever they choose to do.
|
|
||||||
Sadly, I know all too well that Andrew and Swiftgeek will never trust me; such
|
|
||||||
is even stated in Andrew's article.
|
|
||||||
|
|
||||||
Their work in Libreboot's Git repository will be fully preserved. They are free
|
|
||||||
to continue their work, and I hope they succeed! Another coreboot distro can
|
|
||||||
only be a good thing!
|
|
||||||
|
|
||||||
I have nothing else to say. I wasn't sure whether I should address any of this
|
|
||||||
at all, but I think I made the right choice.
|
|
Loading…
Reference in New Issue