HN user

glic3rinu

70 karma
Posts2
Comments32
View on HN
The Synology End Game 11 months ago

Last year I bought a 4bay WTR PRO NAS with an N100. It idles at 13W, after some tuning (mostly putting drives to sleep after ~10min of inactivity). I briefly looked into TrueNAS/unraid, but I ended up installing plain Debian, with ZFS, pCloud for remote backups and running everything on plain docker (in my case samba, HASS, jellyfin, kodi, rutorrent and some custom apps of my own). All in all it took me about 8 hours to setup, and 0 issues since. 100% satisfied with my setup.

What you are describing sounds precisely like your brain trying to do some emotional processing and you are shutting it down because you think it's not useful. If you are looking for the productive spin, then I would suggest trying some metathinking. Try to discover why your brain decides to bring this up to your attention. The specific story might seem banal, but uncovering the underlying pattern will teach you things about yourself that you might not be aware of yet, like what you are afraid in life.

I was wondering about that too. Compared to my peers I consider myself having a below average short term memory (not really good at raw computation power), but in contrast, I am pretty good at abstract thinking, e.g. I can easily visualize the end2end flow of a system, identify all the pain points and produce very good designs (in terms of simplicity). So perhaps this "working context" is about knowledge, pattern recognition, analytical thinking, ...

masks dont have the actual shape, but shapes accounting for wave interference patterns that will end up producing the final shape when EUV light passes through. I believe the process of comming up with the correct intereference pattern takes weeks of supercomputing.

Always Do Extra 5 years ago

Building on the web form example given by the author, there is a lot of extra that one could do: Improve the design, improve user experience, improve performance, format/cleanup the code, add some extra features, add flags to enable alternative behaviour ...

OP is talking about concurrent execution of the task without serialization on the database (serializable isolation is almost never the default). Which results in 2 concurrent queries getting the same list of customers to charge.

When I add autoreload functionality to my programs I just spawn a thread that checks for last modified date and then re-executes the program with os.execlp(sys.argv[0], *sys.argv)

I found my solution superior in several ways:

- I can force an autoreload just by saving a file (no file changes needed to force an md5 diff)

- exec() doesn't suffer from the side effects of not restarting the python interpreter, clean start every time :)

- it is also quite portable and doesn't require extra dependencies like inotify/fswatch/etc. </ul>

Consider the incubation time of 5 days avg, 14 days max during which you're already infectious."

I have seen several comments like this on this thread suggesting people are contagious during the incubation phase. Do you have a source for this? AFAIK this has not yet been confirmed, other than perhaps a few anecdotal cases.

A common solution is to wrap all code within a function. This way nothing gets executed until the last line, the one that calls the function, is executed.

  function main () {
     # all code goes here
  }
  main

The interpreter loads reasonably fast, takes around 20-40ms. And it's even faster if "import site on initialization" is disabled.

But startup time increases an order of magnitude once you start importing 'requests' and other common packages.

Perhaps an option to turn imports lazy...

I wouldn’t mind cpython performance improvements over language features. Specifically startup time. Py cli tools can easily take up to 300-600ms to start. Now, try to use them for scripting. A single script doing a bunch of calls to python clis has already several seconds of runtime penalty.

By "state" I think OP is referring to an style of programming heavily based on global variables (global state). Function calls set global variables that the caller can read after. Functions and imports (sourcing) are all riddle with "side-effects", making the execution of the program very difficult to follow (spaghetti code).

Because "return values" in bash are implemented by echoing (printing to stdout):

  return=$(my_function arg1)
I believe OP has the point that echoing friendly-parsable output is a way of implementing "data-structures" in shells.
  result=$(my_function arg1)
  result_a=$(echo "$result" | grep A)
  result_b=$(echo "$result" | grep B)

A mix of the two approaches might yield the best results.

At work I usually go by looking for quick solutions for the very specific problems I encounter, e.g. disable echo on a terminal, send data through a socket, ...

And what I sometimes do over the weekend is to go over the problems I had and try to learn from the subject in a more generic way. e.g. learn TTY inner workings by reading the source code of python's pty.py standard library module, read the socket's documentation and understand all available socket operations, or watch some conference talk on the subject over youtube ...

This second consolidation phase has proven very useful to me. Not only because of discovering interesting gems hidden in standard libraries and other references, but also to be able to anticipate and solve really weird/low-level bugs that otherwise would have been very difficult to approach.

Similar in the sense that they protect data from being accessed by multiple threads at once. But the implementation and semantics are quite different.

The main practical drawback, I would say, is that locks may suffer from the mutual exclusion problem; where you have contention, starvation and deadlocking. Also your ability to parallelize operations over shared state quickly vanishes as the number of threads grow...

With the actor model you don't share state between threads, hence no need to lock anything.

Each variable can only be updated by a single and unique thread. If another thread (or actor) wants to modify it, it has to send a modification request messages to that one thread to do the job.

That's quite a difference!

Edit: Java threading model is fine for limited amounts of concurrency. Complexity escalates quickly with highly concurrent applications; the actor model makes reasoning about those programs far easier.

I believe the problem might be more common when exporting data from one system to another. I've written code to migrate (and merge) large datasets from old legacy systems. I needed quite a lot of heuristics and "best-effort" transformations in order to deal with data inconsistencies... mostly string manipulations where it's not hard to imagine bugs like this happening.