HN user

sudahtigabulan

215 karma
Posts0
Comments135
View on HN
No posts found.

Given that most software hides dot files by default, where do you see them so often?

The only place I've encountered where they are visible by default and do get in the way is bash filename completion, and you can change this via the readline config file:

  # ~/.inputrc:
  set match-hidden-files off

a 60 question test with 50 minutes of allotted time

Is this kind of test - many short questions - a standard thing for math in your country?

My university exams were pretty much all "2-question", in 90 minutes.

The first half was an essay where you have to reproduce a lesson from the curriculum, in your own words.

The second half was "the formulas" - you have to develop one or two formulas from first principles.

I once got an A- even though I got "the formulas" half very wrong. As the teacher explained later, I simply chose the coordinate system beginning at not the same place the textbook did. And this was supposed to be a bad teacher - he actually gave Ds to almost all of us (180 people). This was a makeup exam.

Try publishing on https://repo.or.cz (or another old-style web interface), and just leave an email for contact.

You will hear only crickets.

Adding the slightest friction, and making potential drama 1:1 only, demotivates most people.

You might miss out on an occasional good feedback, though.

Maybe using an unnatural placement of )parentheses( could have worked as a non-conflicting indicator of italics.

Using different delimiter for opening and closing is a good idea on its own, too. I think it makes parsing simpler and unambiguous wrt nesting.

I've imagined something like this:

  `(monospace)
  _(underline)
  /(italics)
  ~(overstrike)
Probably looks a bit more distracting, though.

They sit on disk as plaintext, readable by any process running as your user

The proposed solution:

Instead of loading secrets from a file, you use a wrapper script that fetches secrets from a secure store and injects them as environment variables into your process

Now they sit "on disk" as plaintext, in /proc/self/environ, still readable by any process running as your user.

I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.

Sadly, yeah. And will do anything only if they believe they can actually be caught.

An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago.

A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.

Fifteen Years 8 months ago

Firefox for Android, for one, shows the alt text at the top of the context menu that pops up when you long press an image.

If it's too long, it gets truncated, though.

What were you expecting? That your character ranges in ls would match mine?

I would expect the command to work in any directory. Try a few different directories on your computer and you'll see that it won't work in some of them.

That’s typical usage of Awk, where you use it in place of cut because you can’t be bothered to remember the right flags for cut.

Even you remember the flags, cut(1) will not be able to handle ls -l. And any command that uses spaces for aligning the text into fixed-width columns.

Unlike awk(1), cut(1) only works with delimiters that are a single character. Meaning, a run of spaces will be treated like several empty fields. And, depending on factors you don't control, every line will have different number of fields in it, and the data you need to extract will be in a different field.

You can either switch to awk(1), because its default field separator treats runs of spaces as one, or squeeze them with tr(1) first:

  ls -l | tr -s' ' | cut -d' ' -f3

once you develop a good enough utility library for it.

What happens when everybody comes to the job with their own utility library and start working on the same codebase?

Would you like it if you had to get up to speed with several utility libraries your coworkers developed for themselves?

A common set of tools, like the Unix commands, makes it easier for people to collaborate. They were put in an official standard for a reason.

The 2 minutes wasted to write it doesn't move the needle, but the time that their present and future teammates will waste on reading it might.

It costs me more effort to read and understand a screenful of unfamiliar code than the equivalent "sort -k 1.1" or "uniq" while skimming through a shell script. This adds up.

I think touch screen itself limits the possibilities to create UIs usable with minimum attention. You have to look at it to find the right area to press. All those buttons, knobs, sliders, etc., imitate the real thing, but only in 2D. Can't rely on feeling to find the right control, unlike with physical designs.

It's not the only culprit, of course. There's still room to at least design a layout that is predictable, and with buttons that are easily reachable.

Some UIs make me think the designer was an alien invader in a human body. It thinks nobody can tell, but when it designs a UI that can only be called "intuitive" if you have 7 fingers, the 2-nd and 5-th longer than the others, and the 3-rd one a tentacle... I got you, motherfucker!

This reminds me of ClearCase and its MVFS.

Builds were audited by somehow intercepting things like open(2) and getenv(3) invoked by a compiler or similar tool, and each produced object had an associated record listing the full path to the tool that produced it, its accurate dependencies (exact versions), and environment variables that were actually used. Anything that could affect the reproducibility was captured.

If an object was about to be built with the exact same circumstances as those in an existing record, the old object was reused, or "winked-in", as they called it.

It also provided versioning at filesystem level, so one could write something like file.c@@/trunk/branch/subbranch/3 and use it with any program without having to run a VCS client. The version part of the "filename" was seen as regular subdirectories, so you could autocomplete it even with ancient shells (I used it on Solaris).

If it happens a second time? A stern talk from their manager.

In my experience, the stern talk would probably go to you, for making the problem visible. The manager wouldn't want their manager to hear of any problems in the team. Makes them look bad, and probably lose on bonuses.

Happened to me often enough. What you described I would call a lucky exception.

SML [...] appears to idiomatically represent them as functions of a single tuple parameter

Tuple is not special, though. Functions accept a single argument of any type.

To use the argument in the function body you can name it, or you can use any valid pattern to destructure it and bind parts of it to local variables.

Tuple is just one of the valid patterns. Coincidentally, it looks like argument list with positional arguments in many other languages. You can also use a record, which makes it look like "keyword arguments". You can also use patterns of custom types.

All the above is still about the single "argument" case, the single value that is "physically" passed to the function. Pattern matching is what makes it possible to bind parts of that value to multiple local variables in the body of the function.