Great, thanks!
Great, thanks!
Excellent. Which license would you apply to this? I store many of my small scripts in my personal (but publicly readable) wiki, so I’d like to get the license right for any derivatives I might publish.
I have some experience translating software would like to contribute, but I’m unsure of how the coffee and JSON files in this source tree are related: public/translations/README.md refers to app/translations/en_us.coffee (like the blog post above), but the es_ex and pl_pl translations in public/translations are JSON files without corresponding coffee files in app/translations. Do I base my translation on a copy of en_us.coffee or on one of the JSON files?
The Galaxy Zoo guide refers to a template-creating script, but that gives an error: ”translate.rb:11: syntax error, unexpected ’:’, expecting $end”
@guarinex70 Sorry I don’t speak Spanish, so I’m working with what Google Translate tells me you said. Yes, the flashrom parameter to write the ROM file is -w, the video title shows the exact command I typed in for the procedure. And yes, that’s revision 2101 of the BIOS going in. I downloaded it from ASUS’s site: look for the product page for your motherboard if you have an ASUS, and the Download section there. For this board they’ve since released revision 2102 which I haven’t tried.
1. Raise accessibility alongside the top goals of simplicity and usability,
2. aim for those goals more rigorously than currently,
3. communicate how it’s being done (i.e. how doing things the way they’re done in Gnome contributes to those goals).
I’ve outsourced my desktop getting to the goals I raised in #22 to the Gnome project, and I believe that Gnome aiming for them will eventually result in the noble ”It Just Works” user experience for me and my friends using Gnome. Though it is the best effort currently available to that end, we’re not quite there yet.
Incidentally, I’ve been looking into open alternatives to BIOS the last couple of days due to the fact that very few desktop systems’ BIOSes support setting a hard disk password. This seemed to me like the perfect niche for the free DIY solutions: something that BIOS/mobo manufacturers most likely will not fix due to limitedness of the target market, where said market consists of die hard nerds like me who like weird things such as (gasp!) encrypting their data.
I was disappointed to find that, although Coreboot should work on my setup, none of the open source payload solutions seem to support ATA security either.
So I ended up patching my BIOS with another proprietary blob to achieve what I wanted.
(Was there a point to this? Maybe just that the open solutions that are out there are not only limited in compatibility but, even when compatible, still not the end-all to limits imposed by a proprietary BIOS. Of course, they do have the benefit of being more easily modifiable, so if you know your low-level languages, you can build a custom solution yourself. I just wish I was that competent.)