It is certainly possible, but also implies a complex mix of different income types and very specific national pairing.
The usual case where there is a tax treaty is that the expat pays taxes at the rate of the country in which they work. It's really that simple for most people.
The EU isn't going to get the taxes (certainly not the vast majority of them). They just ruled that it isn't OK for Apple to have been given this tax break via specific accounting rules. It's Ireland that gets the windfall, whether it wants it or not.
It is hard to accept that this is written by someone with any idea about how Linux works (as a Unix).
A process (really, a "task") is a containment and management object that represents a running instance of a program. A program ("task") does not run, its threads do.
The significant difference between Windows-related OS kernels and Unix-y ones is that process creation is much more heavyweight on the former. Nevertheless, on both types of systems, it is threads that execute code and technically run.
Linux is the only Unix-like kernel I actually know anything about. In Linux, processes essentially do not exist. You have threads, and thread groups. A thread group is what most of the user-space tooling calls a process. It doesn't do very much by itself. As the name implies, it mostly just groups threads together under one identifier.
Linux threads and "processes" are both created using the "clone" system call, which allows the caller to specify how much state the new thread shares with the old thread. Share almost everything, and you have a "thread". Share almost nothing, and you have a "process". But the kernel treats them the same.
By contrast, processes in NT are real data structures that hold all kinds of attributes, none of which is a running piece of code, since that's still handled by a thread in both designs.
If you're splitting hairs, you're correct; processes manage threads on all OSs.
However, from the application programmer's perspective, the convention on Unix-likes (which is what really matters) is to fork and pipe between processes as IPC, whereas on Windows this is not the case. Clearly the process start-up time on Unix-likes is considered fast enough that parallelism on Unix until fairly recently was based on spinning up tens to hundreds of processes and IPC-ing between them.
For a certain kind of application programming, that is and was true, yes.
But not for many other kinds of application programming, where you create threads using pthreads or some similar API, which are mapped 1:1 onto kernel threads that collectively form a "process".
I'm not sure what your definition of "fairly recently" is, but in the mid-90s, when we wanted to test new SMP systems, we would typically write code that used pthreads for parallelism. The fact that there is indeed a story about process-level parallelism (with IPC) in Unix-y systems should not distract from the equally fact existence and use of thread-level parallelism for at least 35 years.
My knowledge might be very out of date, but I remember a Linux process being an unit of execution as well as isolation. Creating a process without a thread is not possible afaik.
In contrast, Linux threads were implemented essentially as a hack - they were processes that shared memory and resources with their parent process, and were referred to internally as LWPs - lightweight processes.
I also remember a lot of Unix/Linux people not liking the idea of multithreading, preferring multiple processes to one, single-threaded process.
Linux took quite a path getting to its current threading implementation. Before NPTL[2], there was LinuxThreads[1], before that, I'm pretty sure threads were userspace only.
> The processes section should be expanded upon. The NT kernel doesn't execute processes, it executes _threads_. Threads can be created in a few milliseconds where as noted, processes are heavy weight; essentially the opposite of Unicies. This is a big distinction.
I am not sure what point you are attempting to make here. As written, it is more or less completely wrong.
NT and Unix kernels both execute threads. Threads can be created in a few microseconds. Processes are heavy weight on both NT and Unix kernels.
The only thing I can think of is the long-standing idea that Unix tends to encourage creating new processes and Windows-related OS kernels tend to encourage creating new threads. This is not false - process creation on Windows-related OS kernels is an extremely heavyweight process, certainly comparing it with any Unix. But it doesn't make the quote from you above correct.
On a separate note, the state of things at the point of creation of NT is really of very little interest other than than to computer historians. It has been more than 30 years, and every still-available Unix and presumably NT have continued to evolve since then. Linux has dozens to hundreds of design features in it that did not exist in any Unix when NT was released (and did not exist in NT either).
Processes and threads on NT are distinct nominative types of objects (in a system where “object” has a much more precise meaning) and the GP is at least correct that the former are not schedulable entities. This distinction doesn’t really exist on Linux for instance where there are at one approximation on the user side only processes (at least to use the verbiage of the clone syscall - look elsewhere and they’re threads in part due to having to support pthreads), and the scheduler schedules “tasks” (task_struct) (whereas in NT the “thread” nomenclature carries throughout). FreeBSD may have separate thread and proc internally but this is more an implementation detail. I guess this all to say at the level lower than an API like pthreads, process/thread really isn’t easily comparable between NT and most Unixes.
It’s not so much “heavyweight” vs “lightweight” but that NT has been by design more limited in how you can create new virtual memory spaces.
For better or worse NT tied the creation of VM spaces to this relatively expensive object to create which has made emulating Unix like behavior historically a pain in the ass.
pthreads is a user-space API, and has nothing to do with the kernel. It is possible to implement pthreads entirely in user space (though somewhat horrific to do so). Linux does not have kernel threads in order to support pthreads (though they help).
Anyway, I see your point about the bleed between the different semantics of a task_t in the linux kernel.
> Linux does not have kernel threads in order to support pthreads
Yes, what I was alluding to somewhat cryptically was things like tgids and the related tkill/tgkill syscalls that as far I am aware were added with the implementation of 1:1 pthread support in mind.
Software exposes (at least) two faces ... the user facing one ("habitability") and the (future) developer facing one ("building").
GoF approaches from the "building" side since it was created by and for programmers. Another way of thinking about this is that GoF is describing the experience of the design as a developer having to "inhabit" it, rather than a user's experience of the same.
That's why Alexander is not a particularly useful book for builders, since it focuses on the user's experience of the design when inhabiting it, rather than the constructors' experience of the same design when creating or modifying it.
A version of GoF that focused on the user experience would be a completely different book than the one we know.
That would be true if all credit card customers pay their monthly bills in full, every month.
However, that is not the world we live in. Most people carry balances a majority of the time, with interest rates significantly above "the cost of money".
Further, the banks (really: card issuers) (in the US, at least), are collecting 0.5-4% of all transactions as fees.
And yet somehow, certain ACH payments are "almost" instantenous.
I have automatic transfer of my PayPal balance (to my bank) set up (most of my income arrives via PayPal). Since I did this, the payment is in my bank account the next day, using the amount in the account within a minute or two of midnight.
There's also Zelle, which seems to be slowly spreading (with the emphasis on "slow" - its adoption rate seems far behind Venmo at the same point in Venmo's life).
> Zelle (/zɛl/) is a United States–based digital payments network run by a private financial services company owned by the banks Bank of America, Truist, Capital One, JPMorgan Chase, PNC Bank, U.S. Bank, and Wells Fargo.
What do you think the borrower did with the $hundred-M that they borrowed?
There's only so much you can blow on intangibles. Should there be a major write down in the value of the asset, chances are not bad that there are tangibles to reclaim.
The usual case where there is a tax treaty is that the expat pays taxes at the rate of the country in which they work. It's really that simple for most people.
reply