1. 4

    The Tao Of Backup comes to mind:

    The novice asked the backup master which files he should backup. The master said: “Even as a shepherd watches over all the sheep in his flock, and the lioness watches over all her cubs, so must you backup every file in your care, no matter how lowly. For even the smallest file can take days to recreate.”

    The novice said: “I will save my working files, but not my system and application files, as they can be always be reinstalled from their distribution disks.”

    The master made no reply.

    The next day, the novice’s disk crashed. Three days later, the novice was still reinstalling software.

    I’ve burned myself a few times making assumptions about what parts of my filesystem I really need backups of. In the end, simply backing up almost everything has left me with considerable peace of mind. I still exclude some things from my backups (think /var/cache, /home/*/.cache and the like), but between blacklisting and whitelisting, the former seems preferable for backups. I’d rather have a few gigabytes of extraneous data in my backups than lose even a kilobyte of important data.

    1. 9

      I’m not touching an operating system without even an attempt at package signing with a ten-foot pole, “simplicity” be damned.

      1. 0

        But it’s a source-based distro; you build the packages.

        1. 2

          I don’t build them from thin air, though; I build them from package sources provided by the distribution. I can’t verify the integrity of those sources any other way than downloading them from GitHub and assuming they’re intact. Gentoo is source-based as well, but ebuilds still come with manifests containing checksums ultimately signed with PGP. Trusting the master repository is not a sufficient security model on its own. I probably don’t have to remind you that even GitHub can be compromised, and in fact, has been in the past.

          And yes, of course I could verify the integrity of my package sources by reviewing them before building, but honestly, if I have to review the package build files that come straight from my upstream distro maintainers for security breaches, I’m really left scratching my head over why I’m using the distro in the first place.

          1. 1

            Signature verification has now been integrated into the package manager! https://github.com/kisslinux/kiss/issues/60#issuecomment-538341425

            1. 1

              The author agreed and is now signing all commits from now. The integration of signature verifying to the package manager is tracked here; he’s deemed GnuPG 1.4 simple enough to include in the base system if the issues mentioned are resolved.

              1. 1

                Well, the distro isn’t for everyone. But you do have a point; commits could be signed without impacting the simplicity of the base system, then you could at least optionally set up your system to verify it. I’ve brought it up with the author.

          1. 9

            […], and systemd is pretty much an attempt at a takeover of Linux by big corporations.

            Does anybody have the heart to show this person the commit log of a recent Linux release? They might have to install a BSD afterwards…

            1. 1

              They might have to install a BSD afterwards…

              I’m pretty sure the BSDs enjoy a similar level of corporate contribution, FreeBSD especially, receiving mountains of code and cash from the likes of Netflix and Apple.

            1. 3

              What a satisfying combination of username and submission title.

              1. 10

                Note that Ctrl+Shift+V has nothing to do with Vim; it only happens to be the default paste shortcut in some popular terminal emulators. Vim’s paste option would have been worth mentioning here too.

                I agree with Vaelatern’s comment. The title had me expecting things I “Didn’t Know”. In my view, “5 Common Beginner Tasks in Vim” would’ve made for a more honest title.

                1. 4

                  That seems a bit silly compared to simply generating fixtures at test runtime.

                  1. 5

                    I’m rather glad they don’t exist. How horrifying.

                    1. 19

                      Mentioning the low LOC while using third-party libraries seems like cheating somehow. :P

                      1. 11

                        Nah. That’s penalizing the author for having the strength of character to not succumb to NIH syndrome.

                        1. 2

                          What about packaging all of the app in another library, and keeping a single line in the main repo. Does that count as a single LOC?

                          1. 14

                            I mean, there are myriad ways to play golf, but I personally feel that in this case “89 LOC” is just a way of saying “A really small amount of code for what it does”.

                            You can take potshots for the inclusion of an actual numeric count, and that’s fine, but the substance of the title is something I personally appreciate.

                            1. 5

                              Agreed, you make a good point.

                              I had to look at the “business card” ray tracer again; while having a low LOC, it includes some libraries and uses one letter variables. This submission’s notion of LOC is more production-code-like, which is somewhat more telling.

                        2. 11
                          require 'date'
                          require 'fileutils'
                          require 'kramdown'
                          require 'mustache'
                          require 'yaml'
                          

                          I don’t think this is cheating. Would anybody expect a static site generator to provide its own implementation of Markdown, Mustache and YAML?

                        1. 4

                          I’m still somewhat incredulous that Homebrew has yet to include an officially blessed way of removing unused dependencies. MacPorts provides the optional port_cutleaves utility, at least.

                          1. 7

                            I pray for hardware accelerated video decoding on Linux with every major release, but oh well… CSS-enabled scroll bars are a nice early christmas present too.

                            1. 0

                              I can’t say nothing more than ditto.

                            1. 3

                              Is there a performance advantage over just relying on a terminal multiplexer to do scrollback?

                              1. 3

                                Yes. Whether you care as the user is a different matter.

                                1. 1

                                  this is fascinating. as someone who came up doing scrollback via screen over dial-up, those numbers are as great a generational observation as a technical one!

                              1. 2

                                I think Ruby does this a little better, with the so-called “squiggly heredoc” added in 2.3:

                                puts <<~HEREDOC
                                  Because the boss knows
                                  that what the boss says goes
                                  if the boss's suffered losses
                                  then that's what the boss chose!
                                HEREDOC
                                

                                Relevant documentation.

                                1. 3

                                  Nice to know about – I’ve got a few python scripts that’ll help clean up a bit.

                                  (Note also the <<- here-doc variant, which is similarly convenient when writing shell scripts.)

                                  1. 3

                                    Here docs/strings are awesome.

                                    Another use case I like (beyond ascii art) is embedding test text file contents in a string along with the test itself. When you come back to it later, instead of the indirection of looking up the contents of an external file and cluttering up the file system, you have it right there with the test.

                                    1. 5

                                      Perl has __DATA__, which is places at the end of the code in the file, and everything which comes after you can read with the DATA filehandle (I don’t know where Larry stole this idea from).

                                      So a file looks like:

                                      #!/usr/bin/env perl
                                      
                                      print "here be dragons!\n"
                                      __DATA__
                                      {
                                         "id": 42
                                      }
                                      

                                      and you can read that last bit by passing a filehandle along. Pretty nice to embed simple stuff in test files, for example.

                                    2. 1

                                      Note that the <<- heredoc form only works on text indented with tabs, other kinds of white space will be ignored.

                                    1. 2

                                      I feel like the title ought to say “Web Development” instead of “Web Design”. The article is only tangentially about web design.

                                      1. 2

                                        It depends on ones understanding of “Web Design”. If it means “Graphic Design” for the Web, then yes, the article has not much obvious relevance.

                                        But if “Design” means making decisions wrt. the product one is building (for the Web), like suggested in the quote:

                                        […] consider designing your interface such that it’s easier to use by someone who only has use of one arm.

                                        Then “Web Design” means more than looks: the impact of all decisions on the user experience. That includes conceptual, graphic, and technological considerations. As such I found the article to be a nice compilation of the problems we cannot control, where things like SSL, DNS etc. are just the things which are most obviously broken when they do not work.

                                        1. 2

                                          This may actually be a cultural difference. I’m from Germany. Most—if not all—people I’ve worked with understand “web design” to mean the graphical design aspect; I also think this understanding of the phrase makes more sense, though of course, that may be bias on my part. Perhaps there’s a case to be made for a distinct term to encompass the design of user experiences, something like “UX design”.

                                        1. 3

                                          I guess the target audience is less in people who are free to choose their means of communication but more in people who are forced to use Slack if the wan’t to keep their current job. Like so many proprietary products before, Slacks secret of success not so much in its technical merits as in its marketing department.

                                        1. 7

                                          One wonders why not just, say, use JSON for this.

                                          1. 24

                                            I believe the prefs format predates JSON (or at least JSON’s popularity), and changing it now is a non-starter as it would break everyone’s user preferences. Even this changeset whose only backwards incompatible changes were fixing some glaringly obvious bugs caused some reports of failing CI around the web.

                                            We could try to migrate prefs files to a new format, but that would be a high risk/low reward operation.

                                            1. 5

                                              We could try to migrate prefs files to a new format, but that would be a high risk/low reward operation.

                                              I wish you folks would do that. :(

                                              1. 19

                                                Would you volunteer to respond to all the breakage reports it might cause?

                                                I may sound bitter now, but when a maintainer says something is too hard/risky, and a random user replies with “yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.

                                                1. 17

                                                  Respect doesn’t enter into it–hell, I even agree with the assessment that the work is high-risk/low-reward…then again, I feel the proposed fix has some of the same issues. Like, the parser has worked well-enough that refactoring is maybe not a good use of time.

                                                  If the decision is made “We must refactor it”, then it makes sense to go one step further and fix the underlying file format anyways. Then again, Mozilla has a history of derping on file formats.

                                                  As for “all of the breakage reports it might cause”, given that the docs themselves discourage direct editing of files, it would seem that there probably isn’t a huge amount of breakage to be concerned about. Further, if the folks are clever enough to write a neat parser for the existing format, I’m quite sure they’re clever enough to write a tool that can correctly convert legacy config files into a new thing.

                                                  (And again, it’s common advice that there are no user-servicable parts inside good chunks of it, because it’s a derpy file format.)

                                                  Like, just to hammer this home, here is the format of a prefs.js file:

                                                  # Mozilla User Preferences
                                                  
                                                  /* Do not edit this file.
                                                   *
                                                   * If you make changes to this file while the application is running,
                                                   * the changes will be overwritten when the application exits.
                                                   *
                                                   * To make a manual change to preferences, you can visit the URL about:config
                                                   */
                                                  
                                                  user_pref("accessibility.typeaheadfind.flashBar", 0);
                                                  user_pref("app.update.lastUpdateTime.addon-background-update-timer", 1520626265);
                                                  user_pref("app.update.lastUpdateTime.blocklist-background-update-timer", 1520626385);
                                                  user_pref("app.update.lastUpdateTime.browser-cleanup-thumbnails", 1520640065);
                                                  user_pref("app.update.lastUpdateTime.experiments-update-timer", 1520626145);
                                                  user_pref("app.update.lastUpdateTime.recipe-client-addon-run", 1520626025);
                                                  user_pref("app.update.lastUpdateTime.search-engine-update-timer", 1520625785);
                                                  user_pref("app.update.lastUpdateTime.telemetry_modules_ping", 1520625905);
                                                  user_pref("app.update.lastUpdateTime.xpi-signature-verification", 1520626505);
                                                  
                                                  <snip>
                                                  

                                                  There is no reason that this shouldn’t be in a sane file format (read: JSON). This could be accomplished with a conversion tool, and gracefully deprecated.

                                                  Edit:

                                                  It even already contains JSON!

                                                  user_pref("browser.onboarding.tour.onboarding-tour-performance.completed", true);
                                                  user_pref("browser.pageActions.persistedActions", "{\"version\":1,\"ids\":[\"bookmark\",\"bookmarkSeparator\",\"copyURL\",\"emailLink\",\"sendToDevice\",\"pocket\",\"screenshots\"],\"idsInUrlbar\":[\"pocket\",\"bookmark\"]}");
                                                  user_pref("browser.pagethumbnails.storage_version", 3);
                                                  
                                                  1. 7

                                                    No disrespect taken :)

                                                    For the record, I agree a standard format would be better. Also for the record I’ve never even looked at the prefs code before, so my statement was coming more from experience knowing how much the tiniest changes can blow up on the scale of the web.

                                                    You never know, maybe we’ll support JSON and the legacy format at some point, but that smells like it might be unnecessary complexity to me.

                                                    1. 2

                                                      You said unnecessary complexity. Normally, I’d either say that’s a good thing or suggest a simple subset if it’s something like JSON. If Firefox already supports JSON, wouldn’t there already be a component included that could be called to handle it? Is that inaccessible? Or does it suck so much it’s worth rolling and including ones’ own parser that’s not a cleaned-up, subset of JSON? Just curious given Firefox is an older, big project.

                                                      1. 5

                                                        The pref parser is a small isolated module, so I don’t think it would be technically difficult to implement (bear in mind I’m not familiar with it at all).

                                                        The complexity I’m referring to was more around ux, maintenance, and support, that come with providing two different ways of doing the same thing.

                                                  2. 2

                                                    ““yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.”

                                                    Bringing up respect and morals when a FOSS project uses non-standard formats instead of standard ones that already existed with tooling people could’ve used? And that definitely would need extra work or fixes later? I doubt they were thinking of morality when they did it. More like “Let’s implement this feature the way I feel like doing it with my preferences and constraints right now.” Kind of a similar mindset to many people asking them for changes.

                                                    A better question would be, “Is replacing non-standard stuff in the browser with well-supported, standardized stuff worth the effort to fix the breakage?” In this case, I’m not sure without knowing more specifics. The general answer for file formats is “Yes wherever possible for interoperability and ecosystem benefits.”

                                                    1. 6

                                                      non-standard formats instead of standard ones that already existed with tooling people could’ve used

                                                      That’s untrue, the grandparent comment mentions this probably predates JSON’s popularity.

                                                      Edit: Yeah, the bug itself is 17 years old, and the prefs format is probably older. Wikipedia says “Douglas Crockford originally specified the JSON format in the early 2000s;”, which means that at best the prefs format came around the same time Crockford first specified it, and at worst it probably came into being a couple eyears earlier.

                                                      1. 1

                                                        Good thinking on the history. I did say “standard formats,” not JSON. Before JSON, the formats I used included LISP-style sexprs for easy parsing, Sun’s XDR, ASN.1, and XML. I also hoped simpler ones gaining popularity would lead to secure or verified implementations. That was effortless for LISP-based syntax with Galois doing a verified ASN.1 later. Most went with the overcomplicated formats or hand-rolled their own each with problems. For XML, I found I could just use a subset of it close to basic HTML tags that made it easier for someone to convert later with standard or customer tooling.

                                                        So, those were among alternative approaches back in those days that many projects were taking. Except LISP syntax which only LISPers were using. ;)

                                              2. 3

                                                Or Toml, since that’s Rust’s go-to data markup language.

                                                1. 4

                                                  That’d be just a little too cute.

                                              1. 2

                                                The “Webmaster” at the bottom of the page is so wonderfully quaint. :)

                                                1. 7

                                                  A E S T H E T I C

                                                  Any chance you could get lynx looking at lobsters? :3

                                                  1. 9

                                                    Sure thing!

                                                    https://u.teknik.io/bfG9p.jpg https://u.teknik.io/rAyqc.jpg

                                                    Is it everything you were hoping for?

                                                    1. 2

                                                      Oh man, I was hoping for a screenshot of this thread!

                                                    2. 2

                                                      Casually shilling for a possibly relevant project

                                                    1. 4

                                                      Guy runs into two bugs involving stale data and concludes every app must have a refresh button? That seems a bit presumptuous.

                                                      1. 18

                                                        That’s kind of reductive. The message I got from the post was “please provide users this simple and well-known way to work around synchronization bugs“. It’s usually easy to implement and has no drawbacks save for a tiny bit of UI clutter.

                                                        1. 1

                                                          Okay, I see your point. I’m partial to the pull-to-refresh affordance since it stays out of the way the 95% of time you don’t need it. In apps that aren’t list-based, however, I don’t know what you’d do (shake-to-refresh?).

                                                          I think I was irked by “every app that doesn’t have this is broken” and the assumption that the web-based paradigm of throwing everything out and getting a fresh copy is the best one for every app. In some apps, it’d be the equivalent of an elevator door close button, where hitting it doesn’t really do anything it isn’t already doing.

                                                          I also think the real issue is how phones react to (or don’t) changes in network connectivity.

                                                        2. 8

                                                          The author uses two examples to illustrate the fact that every application which synchronizes can get desynchronized (seriously, every single one) and providing users with a workaround is essential.

                                                          1. 5

                                                            Going to have to agree with OP. Sometimes a refresh button doubles as an invaluable debugging tool.

                                                            1. 4

                                                              Does it? It seems, at best, like a way to work around bugs by destroying the state you probably need to debug the problem.

                                                              1. 9

                                                                As a user, what does destroying debug data matter to me? I’m not trying to debug your app, I’m trying to call a taxi. Further, how does omitting the refresh trigger help debugging? Most people don’t file bug reports, they just get annoyed, and denying them the tools to fix their problem will just make them more annoyed.

                                                                If you want debug information, I’d argue a refresh button could be actively helpful: users press it when they think something’s stale, so by collecting telemetry on refresh presses you can get a clue as to when desynchronizations happen.

                                                                1. 2

                                                                  I’m not asserting that you shouldn’t have one, I just don’t think it’s a debugging tool.

                                                                2. 1

                                                                  Provide a refresh button in release, but not debug so that developers can’t use it to ignore real bugs :)

                                                                  1. 1

                                                                    Just because I have a hammer doesn’t mean I just go around hitting everything like it’s a nail…

                                                                3. 1

                                                                  Even Gmail on Android allows the user to manually refresh despite it being timely, correct, and not error prone in 2017. I give some odds that the refresh action doesn’t do anything except address the user experience.

                                                                  Not defending buggy apps, but there is a take-away here.

                                                                1. 2

                                                                  Can it even be called a proper contest when there were only two participants and four submissions in total?

                                                                  1. 22

                                                                    Yes, it can. It was open and advertised for multiple months and this were the submissions we got.

                                                                    Everything starts small, and the resulting submissions are interesting.

                                                                    1. 2

                                                                      Fair enough. The name of the contest made me expect more submissions for some reason.

                                                                      1. 14

                                                                        Well, you have to pick the name before the submissions. :) We’d have preferred more, but there will definitely be a re-run, given that the submissions show an interesting gamut of things you have to watch out for Rust:

                                                                        • Soundness holes: One of them uses a (not yet fixed) soundness hole in borrow checking
                                                                        • API behaviour: Even if it’s not broken, it can be surprising. No one can keep all exact behaviours in their head all the time. One uses the behaviour of Path.join, which is similar to Pythons
                                                                        • Environment: One uses the fact that deploy environments may have a copy of the crates.io index.

                                                                        Still, we’re quite happy that no one found ways to hide something that are absolutely specific to Rust. Our running theory is that Rusts aversion of implicit behaviour helps a lot there.

                                                                        Now, this is in no way a proof of this theory: the number of people that know every corner of the language is smaller for Rust then for C, so maybe there’s stuff that just wasn’t found yet.

                                                                        1. 4

                                                                          This bug? It’s still open.

                                                                          https://github.com/rust-lang/rust/issues/38899

                                                                          1. 3

                                                                            Correct, fixed the description. I’m currently gearing up for running RustFest, so I wrote it down from memory.

                                                                            I mixed it with this one, which is fixed: https://github.com/rust-lang/rust/issues/41622

                                                                            Thanks for the critical reading :)

                                                                            1. 3

                                                                              Any time. :) wasn’t sure if I’d missed something.