534 karma · joined June 1, 2016
Driver support for new hardware platforms or one where the hardware producer does not help enough might not be that good: I think Intel's Skylake platform might serve as a good example – an older Linux kernel had a bug where laptops would crash when the lid was closed; now that Skylake is older the bug has been fixed.
That being said, Linux has drivers for many more stuff out of the box than every other operating system. Of course, for the perfect out of the box experience, you have to choose matching hardware – same as with OS X actually.
Ha, I did that as well with Mindstorms RCX in like 11th grade or so! Later, in university, Mindstorms NXT was used: Our first assignment was to follow a track on the ground and the team I was the only one had two programs, one for recording the track with the sensors and another for following the previously recorded track in high speed without using sensors at all.
I am 28 years old and find it hard to read as well. People who choose small font sizes and low contrast degrade usability a lot. Here is an article about the numerous failure modes of low-contrast designs: https://www.nngroup.com/articles/low-contrast/
> While MIME sniffing increases the web experience for the majority of users, it also opens up an attack vector known as MIME confusion attack.
The header tells the browser to stop shenanigans and behave.
Moxie Marlinspike asserts that federation needs standardization and that standardization inhibits changes. He also asserts that protocols have to change to keep up with changing requirements. His unspoken assumption is that it is impossible to create real-world forward-compatible protocols.
While I agree with the first assertion, I strongly disagree on the latter two. Consider that protocols and data formats that do not have to change exist. An encoding like UTF-8 will probably never have to change to keep up with new codepoints. Also consider that forward-compatible protocols and data formats exist. HTTP seems to be a very good example for that.
Did you look for a new job as soon as you knew?
https://en.wikipedia.org/wiki/User:Isomorphic/Minions_of_the...
https://en.wikipedia.org/wiki/Category:Suspected_Wikipedia_s...
If the Microsoft versions of curl and wget were compatible with the original utilities, there would not be any problem.
Is this voting brigading / shilling or just normal behaviour of groups trying to suppress dissenting voices?
Also, is this part of why semi-noobs think that HN is turning into reddit?
To recap:
1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the 'simple' standard.
3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
I use the conkeror web browser [1] and have included the following code in my $HOME/.conkerorrc/config.js and execute “wbsave” for many documents (even my own) whenever I send the URL to someone else.
define_webjump("wbsave", function(url) { return "http://web.archive.org/save/"+url; } );
[1] https://en.wikipedia.org/wiki/Conkeror[1] https://en.wikipedia.org/wiki/ReStructuredText
[2] The book can be downloaded for free: http://internetmeme.de
[3] About the writing process: https://news.ycombinator.com/item?id=12311546
• reStructuredText [2] looks superficially similar to Markdown, but is vastly more useful: It has more features and a defined specification without ambiguities. Many RST processors do not follow the specification in edge cases, but at least it is clear how the document should be layouted. The author of Pandoc [3] fixes bugs very quickly. The Sphinx document processing system [4] can export to HTML, PDF, LaTeX, Epub etc. and can check included URLs automatically (we did not use it for the final version).
• Using Git is a good idea even if you are writing alone: The web interface for our repository and Sparkleshare – a DropBox-like interface for Git [5] – helped immensely with reviews. Gitstats [6] helped me to find out that crunchtime before a deadline always led to at least a few days of writer's block, which enabled me to gauge what amount of text I could write in a sustained manner.
• If possible, save everything relevant to the book in your repository. One example: I investigated the origin of the first lolcats (“Happy Cat” [7], it came from promotional materials of Russian distributors for the “Happy Cat” cat food brand), but have lost some of the emails related to the investigation. Similarly, footnotes in our printed book are now exhibiting link rot. Both of this could have been prevented by importing all source materials in the repository for our book and making sure that all the web pages we mentioned are archived in the Wayback Machine [8].
• The file format of the text matters for interoperability, but which text editor you use does not. Do not learn a new editor for the project if you are already comfortable with one. I used GNU Emacs while my co-author used GNU nano; we never had any problems due to that.
• Me any my co-author worked remotely for the most time. Each evening we had a short chat about what each of us finished during the day, what we were working on, and what plans we had for the next few days. At least for me, telling someone else what I did boosted my motivation; having such a routine process helped me to overcome writer's block.
• There seem to be at least two different writing modes. I think a long time about what I want to write and then write the text, making a few cosmetic changes later. My co-author writes a rough draft and then refines it with each pass. This means that my text is always of the same quality, but he will always meet the deadline. Using Git, we found out he wrote around twice the amount of text as I did, as he re-wrote almost everything at least once. We had no problems with this because we clearly allocated who was responsible for each chapter in the beginning.
• Avoid changing your workflow mid-way or towards the end of the project if you can avoid it, it probably leads to more stress than it is worth. Thanks to publisher shenanigans, we had to send in our texts as multiple ODT files and got it back as one layouted PDF that we had to annotate and send back. One problem was that there seemed to be no software to merge two PDFs with annotations. I quickly hacked up something with Ghostscript only to be told much later that we unintentionally overwhelmed the publisher's pipeline as each one of our around 1000 annotations to the PDF text was apparently faxed to the layouter.
• Get a proper advance. We did not want one and I think it was a failure. You will most likely not make much money with your book – even if it is good and about a popular topic. Three years after the book is published, only around 15 copies are sold each quarter; I suspect it might be one university course using it as classroom material.
• Include a section in your contract about free licensing in case the book is not available. We told O'Reilly we would only accept the contract with a provision that the book would be CC BY-NC-SA and the licensing would switch to CC BY-SA (same as Wikipedia) as soon as O'Reilly stops selling the book. Now that the German section of O'Reilly went under the book is still sold, but by another company that uses the O'Reilly imprint [9].
• Get your hands on as many specimen copies as you can get away with, those are some of your best promotion material in terms of effort vs results. O'Reilly did not do much to promote our book, but they did provide us with copies.
• Do not neglect your loved ones because of work. I regret not having spent more time with the ex-girlfriends I was together with during the time I wrote the book.
[1] The book can be downloaded for free on http://internetmeme.de.
[2] https://en.wikipedia.org/wiki/ReStructuredText
[4] http://www.sphinx-doc.org/
[5] https://www.sparkleshare.org/
[6] http://gitstats.sourceforge.net/
[7] http://knowyourmeme.com/memes/happy-cat