When you spin up a new window with i3, it doesn't retain the previous's current working directory. There are some hacks to make it kind of work, none of which work nicely. With tmux it just works.
tmux has synchronized panes. It allows you to send same keystrokes to multiple terminals at once. This is useful for managing multiple host machines at once, i.e. ssh'ing into different machines at checking certain logs.
Disadvantages:
Double the amount of keybindings you need: one set for i3, one set for tmux. i3 allows you to active a mode where keystrokes are 'forwarded', so theoretically you can use the same keybindings for both, although it is very annoying if you forget to active this mode since you're now creating i3 windows instead of tmux panes and have to clean them up.
Each process can be ptraced by only once process at any time, so if the malicious program want to avoid debuggers, they can attempt a ptrace() on their own process. If it fails, they know they are being debugged.
If you are looking for 'computer science topic' knowledge, I don't think you should search a site 1) geared heavily towards math and 2) seeks to challenge participants (unlike cryptopals, which provides a guide) in the first place.
That's a really good point actually. Perhaps Project Euler has a CS association where it doesn't really belong because it's often mentioned in CS/programming challenges threads, even if it's not intended to be the focus of the exercises.
Using the same language is useful for avoiding duplicated code, personally I find these being duplicated often:
* Form validation/data sanitisation code
* Translation/internationalisation
* Data (de)serialisation
Also you can do fancy things like server-side rendering, although Google is capable of searching SPAs now. I don't know much about SEO.
The argument for less code sharing is that if you are working with a lot of teams and service-based architectures, there are some merits to duplicate your code and keep them redundant, to 1) enable hiring from more diverse backgrounds and 2) reduce communication/maintenance friction needed when you make changes to components would otherwise be shared.
You make a good point- there's really only a handful of things that get duplicated. Maybe instead we should be working on just fixing up those things. Like if there was an easy way to share validation logic from the backend to the frontend... then that would only be needed to be updated once.
That's in the last year. Looks like there are 31 stories total with no (live) comments and > 89 points. But then there are all the ones where people posted about there being lots of points and no comments...
I meant "That's a first" as in it was a first for me. I've seen threads almost empty where the only comments are discussion why they are so empty, but that's usually within 5-6 hours of the thread creation. I've never personally seen a completely empty thread. This seems like an extreme anomaly personally, at least until you revealed the statistics.
The thing about statistics is that while you have a statistical explanation on the population level you still have an individual explanation on the level of individuals.
I found it impossible to debug very large scripts on Firefox. Searching for a string in the script is next to impossible, it would hang the interface for minutes. In Chrome it take seconds to do something similar, you can tell that the script is too big but at least it's debuggable.
Also as a user I cannot bear to use Firefox. I recently retried it (can't recall the version, IIRC it's the first version they introduced multiprocessing) and it still underperforms: I experienced (sub second) lag on UI interactions whereas I wouldn't using Chrome.
You may be right, but in practice the syscall is so limited that I think many programs basically process the syscall as a message anyways, that using a messaging model may make more sense, and be easier to work with.
Someone correct me if I'm wrong, but because of the way the syscall callback operates, it could be interrupting threads at almost any stage. This makes executing the signal in a safe manner very difficult, and from the signal handler itself you can only run certain code. If i remember correctly, most signal handler implementations then get reduced to basically set some state and return, where the regular execution will then check for that state and react to it. Well, if your only going to process the signal during you main event loop anyways, then why not just exchange the information over a message queue, and send a message to the process when you want it to do something (ie reload configuration).
Well, from what I know, sometimes you just have to have out of band communication, check the discussion in the comment here: http://250bpm.com/blog:70
It sounds like a necessary use case to me. While most people would probably not use it, that doesn't invalidate its existence. Most people would probably not touch any low level code either way.
Advantage (of using tmux on top of i3):
When you spin up a new window with i3, it doesn't retain the previous's current working directory. There are some hacks to make it kind of work, none of which work nicely. With tmux it just works.
tmux has synchronized panes. It allows you to send same keystrokes to multiple terminals at once. This is useful for managing multiple host machines at once, i.e. ssh'ing into different machines at checking certain logs.
Disadvantages:
Double the amount of keybindings you need: one set for i3, one set for tmux. i3 allows you to active a mode where keystrokes are 'forwarded', so theoretically you can use the same keybindings for both, although it is very annoying if you forget to active this mode since you're now creating i3 windows instead of tmux panes and have to clean them up.