Commit 2d8fe724 authored by sajolida's avatar sajolida

Remove Mac compatibility list from blueprint

We rejected this idea on Redmine because it seemed to far fetched to be
worth keeping. Now that Mac users can install Tails as well as PC users,
they also don't deserve it more.

Once installed, it's actually easier to start on Mac than on PC.
parent 4bb803eb
......@@ -92,16 +92,6 @@ would require lobbying both Mozilla and Chrome. An alternative could be
to rewrite the checksum calculation in
Mac compatibility list
Mac users still face the most complicated situation, with no graphical
technique for USB and unpredictable hardware. If no
[[!tails_ticket 11682 desc="graphical installation method for macOS"]]
can be found, this could be improved by
[[maintaining a list of Mac models and their compatibility with Tails
and our different installation techniques|assistant/mac]].
Better booting instructions
[[!meta title="Mac compatibility list"]]
As part of the initial implementation of the [[installation assistant
for Mac|install/mac]] we based our work on generic installation
instructions that should work in all cases. But depending on the Mac
model, these can imply try and error, and being much more complex than
they would be if we knew in advance the model of the Mac and which
techniques work for it.
While working on this first implementation, we proposed maintaining
and guiding people through a list of Mac models and their compatibility
with Tails and our different installation techniques.
[[!toc levels=3]]
Truths about Mac (in 2015)
- No DVD on some model
- DVD works on 32-bit UEFI
- Reported to fail very rarely (cf. known issues)
- MacBookPro (early 2011) fails to boot from DVD since Tails 1.1
- dd
- Not working on:
- Macbook Air 1.1: 32-bit UEFI
- Macbook Air 3.1: 64-bit UEFI
- 32-bit might work with next version (#8471)
- Tails Installer
- 32-bit doesn't work with Tails Installer
- 64-bit work sometimes yes and sometimes no
- rEFInd
- Don't ask people to do that
- Bootcamp
- No good
List of compatibility with Mac
Redmine ticket: [[!tails_ticket 9150]]
### Bootstrap
- Specifying the data type.
- Know the precise models. ([[!tails_ticket 9322]])
- Setup a git repo.
### Start to fill it
- Frontdesk starts to fill it
### Have it on the website
- Full list in markdown thanks to a routine
- In the web installation assistant
- In/linked in the troubleshooting section
- Maybe later an interactive app in the assistant
Data type
The data could be stored in a YAML file, in the git repo. See [[!tails_ticket 9892]] for work in progress.
- Fields ("strings", boolean?):
"model id"
- "Tails version" | DVD? | dd ? | tails installer? | SD? | wifi? | gaphic card? | mac address?
- ... (an other user reports on this model)
Writing the report after the summit, I would add :
- Anonymised uniq identifier per users
- Timestemp
- Comments (if there is non anticipated things to keep)
- Explicit say if the device type and if it boot or not (I feel it's easiest to write and read)
Trying a yaml type (optional or not):
model_id: (required)
- date: (required)
user: (optional)
media: (required)
boot: (required)
install: (required)
wifi: (optional)
mac_spoofing (optional)
graphic_card (optional)
comments: (optional)
And some samples :
model_id: MacBookAir3.2
- date: 2012-08-06
user: Oothai1iu6iefaiy
media: usb
boot: true
install: tails_installer
Touchpad not working.
- date: 2012-07-26
user: seyuo4daiChei3Oo
media: sd
boot: true
install: tails_installer
wifi: true
mac_spoofing: false
- date: 2012-06-12
user: aif0ueveeb0Ahkii
media: dvd
boot: false
Tried to boot on external DVD. Tails is on not on the Mac boot menu.
* "model id": [[!tails_ticket 9322]]. For one model id, there is one or several reports. (note that there is not realy the "state" for one model: the is different reports who can help to guess the state.)
* "Tails version": can be useful to:
- Have a better view of how the support Mac evolves.
- Let the user or frontdesk know when the compatibility got broken.
* "mac_spoofing": Is mac spoofing working with this computer
* "graphic_card": Is the graphic card working on this computer.
* We want to keep history of compatibility (with older Tails
versions) in this file, maybe we will have to show to the user only
the last relevant informations.
* "Comments" is raw information on harward issues (touchpad, bluetooth). The most common issues are fields (wifi, mac spoofing, graphic card)
How to feed the list
- Call to heavily test sometimes
- Ask to people doing Tails trainings
- Update from frontdesk
- Maybe something editable by users
Later implementation
In the Mac page of the router, we could implement this in two ways, that
could be two iterations.
### All information (without form)
- Raw data is transformed server-side into an HTML table with links to
the available scenarios for each model (maybe using
- The full list is included in the HTML page sent to the user by hidden
in toggle by default.
- Some information is displayed to help the user identify his type of
Mac (maybe simplifying <>).
- The user can toggle to display the sublist corresponding to her type
of Mac (iMac, Macbook, MacBook Air, etc.)
- If JavaScript is disabled, the full list is displayed.
### Only relevant information (with form)
- Some information is displayed to know easily what kind of mac is
- The user types in a form the serial number of her Mac or clicks in a
dedicated tiny wizard like <>.
- Some server-side code (Ruby?) or client-side code (JavaScript) gets
the relevant model and displays the possible scenarios.
- If implemented in JavaScript, it would fallback on the "without form"
version described earlier.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment