I should add that Pascal code tends to be factored along the line of 'things that can be done in Pascal vs things that need or should be done in assembler' rather than C's 'things that are portable vs things that are architecture and platform dependent'. This is really what makes Pascal a dead end. There is a huge, huge body of great Pascal code out there from the 80s - virtually all of it abandoned today. C code from the same era however has generally continued to evolve into what's in use today. Reusability is the real reason it's used while Pascal isn't.
I agree. On the other hand, what can one do in C and cannot do in Pascal?
You might as well ask "what can one do in assembler and cannot do in Pascal?" C is for creating cross-platform system software. Its main benefit is its cross-platform-ness while providing virtually all the capability of assembler. Pascal that has been extended for system software (e.g. Turbo Pascal) is non-portable while a fairly poor substitute for assembler. Even TP would be difficult to use for something like an interrupt handler or thread scheduler. As a result, a lot of TP code contained large amounts of inline-assembler and was rarely factored for portability. Other platforms, like MacOS and the UCSD p-System, that relied on Pascal for programming were largely implemented in assembler.
I am the sort, though, who thinks that nobody should code in anything except maybe BASIC until they're exposed to some Assembly Language. Learn what you're actually moving electrons around in. Quit with the abstraction. Until a little later, anyways.
I would tend to agree with this. Start with some easy to use language (I think python is a very good learning tool since it can teach concepts basic can't - like data structure, functional programming, threading, and networking) just to get started with a broad 30k ft view of what computers behave like for the end user. Then start with the lowest level - the machine itself. Doesn't terribly matter which one - any von neumann architecture conveniently available. I think ARM is good personally because it's easy to program but exposes the details. Easier than Sparc or MIPS to get started with, while more transparent and less 'magic' than x86. Then switch to C as a portable assembler and learn things like inline assembler and factoring for portability. Give students projects to port say code from x86 or MIPS to ARM; let them go research the source machine and figure out how to get it to run on a different machine, refactoring as needed without losing the ability to build for the original architecture. While this may seem like a trivial skill I think it's important to teach students to conceptually distinguish portable system software from machine dependent parts. Understanding the value of code reuse is a driving factor for many higher level concepts, like OO factoring and switching from C to C++ (sans rtti or exceptions) - because of its better code reuse. As part of this students could look at things like the Sun vnode layer as an example of OO factoring in C, and imagine how much cleaner it would read in C++. Then the education keeps building like this until it meets up with the higher level interpreters where it started. (And which are consistently used throughout the education to explore new concepts, like network protocols, transactions/atomicity, or RPC mechanisms.) I think the real issue ends up being how much someone can be taught in four or five short years. It's not much time.
No, I'm a programmer; I was referring to the fact that there are individuals working as programmers who only touch abstract Java code, and have little knowledge of how computers work.
This is really not such a bad thing. While the class in the story is a very elementary introduction to programming (for which all the various interpreted, easy to learn and use languages are great), the real problem domain for CS is, or should be, computing in itself. It should be about making computers easy to use for non-CS people so they can write programs in python, excel, Java, Pascal, or whatever their preference of the day is to implement business systems for their problem domains. No matter what the paradigm of the day is, there will need to be systems implemented to do these things: web servers, database servers, compilers, kernels, runtimes, etc don't just magically appear out of nowhere. And even though these paradigms shift around computers essentially work pretty much like they did 35 years ago, and the system software building blocks are the same. A queue is a queue, a scheduler a scheduler, atomic transactions are still atomic, etc. While some minor things change, the problem domain is the same: implementing programmable, efficient, reliable, useable systems. What's mainly changed is the problem domains of the user. But a computer is still a computer, and someone who did kernel work in 1985 could easily pick up Linux or a web server like Apache today. You still need C and assembler, still need to understand how the machine works, need to understand things like pipeline hazards, cache locality, bus arbitration, etc.
That said though, I'd be skeptical about anyone enrolling in a CS program without knowing how to program in e.g. python or Java. In fact, I'd assume they do and they're actually motivated by a desire to implement and understand runtime tools like this for themselves. But it's a good starting point to study algorithms, or at least the abstract part of them. An efficient implementation then clearly requires some degree of machine knowledge and tools that can leverage benefits while avoiding pitfalls. (It's a typical prototype to production step for this domain.)
Yes, why should anyone be concerned that their ability to afford food and heat in their declining years is dependent on the long-term stability of a system that can be radically damaged by a single mistyped letter?
I guess we're all just lucky this guy hit "b" and not "z".
Not only that, but a system where nobody even knows for sure why it even dropped in the first place! Maybe it was a typo? Maybe it was overseas? Maybe something else? Maybe our savings will be there when we retire? Maybe not?
How about if we start applying the same dumb blind belief to software engineering... Maybe it'll work? Or if it fails, lets design it so it's impossible to tell why! Let's just guess! Blind belief!
It just doesn't feel right to have something so flakey and ineptly designed so centrally positioned in our economy...
And when your 'Organic Only' store is carrying a hybrid/cross breed that occurred in nature (that no one is testing for) you still have consumed a GMO crop.
They DO random genetic testing you know. There are independent labs that test for GM markers, and distributors and retail chains that sell GM-free products do use them. That's not to say that a GM strain can't accidentally make it into the pipeline, obviously it's bound to happen. However, I personally am not too concerned with the occasional accident as much as the regular daily stuff.
I'd expect a libertarian to hold the view that if you contaminate your neighbors' soybeans or corn you're liable for cleanup and replanting, as well as medical care to people who ate it. This in turn would force growing to be geographically separated so as to prevent cross-pollination - or if that's not possible GM crops would be a commercial dead end. The liability litigation would simply bankrupt anyone who tried to grow it.
However, in the real world as opposed to libertarian utopia the best is probably to simply restrict growth of GM strains to laboratory settings.
All you "free market" enthusiasts out there, answer this question for me:
How would the unencumbered "free market" handle a problem like this?
I'm not a free market enthusiast, but even I can answer this: you take your business to a store that doesn't carry GM produce or products that contain it. My local Whole Foods store, for instance, is GM-free and predominantly organic.
If they had decided to start using 64-bit time on the 1st of January, 1970 none of these problems would have happened
The pattern:
##{ FH_DATE_PAST_20XX
header FH_DATE_PAST_20XX Date =~/20[1-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX
Will match 2010 no matter how many bits are used to keep time. This is a problem that has been know for years; it's a total embarrassment to OSS practices that it wasn't fixed before 1/1/10, before becoming critical. It's not based on a bad architectural decision, or even particularly bad code - it's just a typo where the fix wasn't pushed in a timely manner. I suspect a problem here is that open source development doesn't separate bug fixes from feature additions, which means non-critical fixes get backed up with features to be considered stable enough to ship. A critical fix can be spun separately (being backported to the current stable branch) - but this problem wasn't critical... yet...
It's not high at all, $32M is peanuts for three mass market software products of this size and complexity. The more interesting question is why it has taken them so long to get where they are today. The answer to both questions lies in the fact that they work with enlisted personnel - for whom this may be their first job. They're cheap and enthusiastic, but slow.
As a CS student I think you should focus on product development, not IT. You absolutely should intern at a technology company whose main focus is products - and whose _customers_ may include IT departments. You won't be paid a whole lot, but the tasks you get will also be very simple, relatively speaking, and while they may be important, once taken care of you'll have plenty of time to poke around with whatever interests you. You may be asked to say add an option to a compiler, tweak a kernel build, or add data gathering and instrumentation - things that the other developers would like to have but don't find time to do themselves. If in the process you find something you think might make an interesting project by all means suggest it, chances are you'll get to go do it, unless it seems overly ambitious to the extreme.
Does the article discuss how much info each user leaked? I wouldn't be real surprised if the older users posted less info and were thus less concerned with privacy (It also wouldn't be shocking if they were simply less aware of it).
I guess at 45 I qualify as "older" in this context. I don't post personal details, or say things I don't want my business contacts to be aware of. FB serves the same purpose to me as a cocktail party - it's just a simple social function. I don't really care who wants to be my friend (which I view more as a 'live rolodex') - you never know who might be handy to know. I have about 300 friends on FB. My wife, who's a freelance writer and has to network as part of her business, has over 1500. It's just a tool, and like any other becomes what you make of it. I personally like it better than LinkedIn, which is too formal.
However it might have ran, it certainly didn't 'save screens.' Back in the day I saw many many CRTs with their phosphors permanently 'burned' by the SETI@Home display:
No kidding, I was always wondering how they got away with billing it as a screensaver. I left my PC powered on accidentally when I went on a four week trip in 2004 and came back to a 24" Sun CRT with SETI@HOME permanently burnt into the center. Screendestroyer is more like it.
All out nuclear war would largely limit damage from the initial detonation and fallout to the northern hemisphere.
Perhaps, but if the northern hemisphere becomes uninhabitable a billion or so people will want to migrate south. The northerners will still be the most heavily armed in the world, have a long history of manufacturing excuses for wars that are thinly disguised land grabs, and aren't going to take no for an answer.
I practically never get sick and I have no known allergies. As a child, I dug in mud, I explored forests, I ate earth and worms and all kinds of crap. Perhaps that's the reason.
So did I - spent time in the local woods, swam in the lakes, jumped in every muddy puddle to be seen, played out in the rain, and whatnot. I'm still allergic to cats, some detergents, and natural rubber (latex, avocado). This was in the mid 70s, and people had allergies then just like today. It's just the bar was much higher and people didn't really consider it an allergy unless they were likely to go into shock or develop serious symptoms. A little spring sniffle caused by pollen wasn't really hay fever unless it caused breathing difficulties or made your eyes puff up so bad you couldn't see. Anything else just wasn't bothered with and parents would tell their kids, "yeah it's just a little spring pollen, now go to school."
I usually vote libertarian but I'd be all for banning smoking in public.
But what? There's nothing inconsistent about that - the air isn't your property to do with as you wish. It's held in common trust, so rules for its use (and abuse) is set through democratic political process.
I see how you come to that conclusion. But, it is false. No reason why the inputs and outputs can't be on separate buses and no reason why you can't have separate machines communicating over yet another bus or set of buses to build a pipeline.
Ah yes, that would be a pipelined design. I think that would work more efficiently than the original DDJ story's.
One version I found in my notes use a one instruction machine to implement the microcode for another machines.
I think too much significance is place on the "single instruction" aspect; the DDJ design is really "single instruction format". It clearly has multiple operations, and the destination address is more or less an opcode field. So it's more accurate to describe it as a single-instruction format machine. Each operation has its own dedicated destination register which can be used as a source for operations.
BTW, this kind of architecture makes it easy to add multiple execution units. With parallel execution and careful use of shared and private FUs and memories you can build a pretty damn powerful special purpose processor without a lot of hardware complexity.
All the execution units (aka co-processors in modern parlance) are still attached to a single bus, so theoretical max throughput is still one instruction per cycle. So this only makes sense if the CPs perform complex operations - like memory management, floating point, mul/div - or something of similar complexity. For the typical simple integer instruction that tends to dominate code it's no better than a microcoded processor - since now each normal instruction requires several cycles on the bus.
Compare this to a pipeline, where each step is what you'd consider a FU, but each one only needs to interface to the previous one, not counting the occasional clever bypass and special linkage. In a pipeline each FU can be fed an input in one cycle and provide an output in the next, something "FU"s (CPs actually) on a shared bus can't.
The other drawback is that anything that goes on the bus needs to implement a generic bus interface and its own internal sequencing logic. This doesn't come free. This is really just a CISC in silicon with exposed microcode, and it's pretty clear the author is thinking CISC all the way as can be witnessed by the stack operations. The typical RISC approach is to have a link register where the return address is placed on subroutine calls, so leaf functions don't have to push/pop it from the stack. Non-leaf functions start by saving the link register to the stack frame in the function prologue once space has been allocated for it.
ARMv6 and up, there's 'ldrex/strex', which perform a load/store of a word, with the store failing if a non-ldrex instruction or other core accessed the same cache line before the strex. Slightly more efficient, and all you need.
This is a lot like MIPS. And indeed, a RISC processor is pipelined rather than microcoded. In a microcoded design it's not really feasible to execute multiple instructions in parallel. ARM strays a little from the pure pipelined model in that it offers complex instructions like stm/ldm, mainly to make it easier to program and reduce code footprint - which is understandable given is origin as a home computer CPU (for the Acorn).
I think it would be cool to take RISC one step further where a single instruction is broken into 5-7 parts (or however deep the pipeline is), which each part controlling each step in the pipeline. But the assembler exposed a very traditional RISC instruction set similar to MIPS or Sparc, with a naked pipeline model - but then does initial instruction decode and generates pipeline steps instead. So while you might write "bal $a0", meaning store PC in LR, and A0 in PC, the assembler breaks this into pipeline controls over multiple instructions. Doing so would make it easier to fill delay slots and manage hazards, allowing the assembler to optimize the pipeline. Exposing a traditional RISC ISA would make porting a toolchain relatively easy, requiring only a version of gas with a pipeline optimizer. Of course, such a processor would require a slightly different pipeline, but it's somewhat plausible the changes would be mostly simplifications to reduce complexity.
I also can pay myself a 'reasonable' salary out of my total bill rate, that saves me $$$ in SS and medicare taxes. For example, say I bill out $100K. I pay myself a 'reasonable' salary of $40K. That means I only have to pay SS and medicare taxes on that $40K. The rest of the $60K falls through and EOY on my personal taxes, and I only pay regular state and federal taxes on that.
There's a whole cottage industry that helps create single shareholder-employee S corporations purely to reduce payroll taxes. It works - for now - BUT they also vastly oversell the benefits to people who are getting into deep water with limited experience. The IRS will reassess payroll taxes - and can do so at will. They look at your $40k and see how much it would cost to hire someone of a comparable ability, give you some benefit of doubt (say 5-10%), then send you a tax bill for the balance. So while you only make quarterly payments based on $40k, you may get a tax bill based on an additional $80k. $20k is what they may leave as a reasonable dividend payout. Or they could simply decide that $140k is a reasonable salary and what it would cost (including benefits and payroll taxes) to hire someone doing your job. So while you may save a little bit on taxes, it's by no means a slam dunk.
That wasn't the question. The question was, "Why shouldn't the First Sale doctrine apply to books and not to computer software."
It does. You can read the software as much as you like. You just can't make copies of it - like onto a computer, without a license to do so. Just like the book. But you can sit and read the bits of the disk as much as you wish. You can even give it to your friends for them to sit and read the bits until they get mortally bored with it.
And this is the fundamental difference between a book and software: reading the book is its principal use. It is in itself not meaningful with software.
Slashdot Mirror
I should add that Pascal code tends to be factored along the line of 'things that can be done in Pascal vs things that need or should be done in assembler' rather than C's 'things that are portable vs things that are architecture and platform dependent'. This is really what makes Pascal a dead end. There is a huge, huge body of great Pascal code out there from the 80s - virtually all of it abandoned today. C code from the same era however has generally continued to evolve into what's in use today. Reusability is the real reason it's used while Pascal isn't.
I agree. On the other hand, what can one do in C and cannot do in Pascal?
You might as well ask "what can one do in assembler and cannot do in Pascal?" C is for creating cross-platform system software. Its main benefit is its cross-platform-ness while providing virtually all the capability of assembler. Pascal that has been extended for system software (e.g. Turbo Pascal) is non-portable while a fairly poor substitute for assembler. Even TP would be difficult to use for something like an interrupt handler or thread scheduler. As a result, a lot of TP code contained large amounts of inline-assembler and was rarely factored for portability. Other platforms, like MacOS and the UCSD p-System, that relied on Pascal for programming were largely implemented in assembler.
I am the sort, though, who thinks that nobody should code in anything except maybe BASIC until they're exposed to some Assembly Language. Learn what you're actually moving electrons around in. Quit with the abstraction. Until a little later, anyways.
I would tend to agree with this. Start with some easy to use language (I think python is a very good learning tool since it can teach concepts basic can't - like data structure, functional programming, threading, and networking) just to get started with a broad 30k ft view of what computers behave like for the end user. Then start with the lowest level - the machine itself. Doesn't terribly matter which one - any von neumann architecture conveniently available. I think ARM is good personally because it's easy to program but exposes the details. Easier than Sparc or MIPS to get started with, while more transparent and less 'magic' than x86. Then switch to C as a portable assembler and learn things like inline assembler and factoring for portability. Give students projects to port say code from x86 or MIPS to ARM; let them go research the source machine and figure out how to get it to run on a different machine, refactoring as needed without losing the ability to build for the original architecture. While this may seem like a trivial skill I think it's important to teach students to conceptually distinguish portable system software from machine dependent parts. Understanding the value of code reuse is a driving factor for many higher level concepts, like OO factoring and switching from C to C++ (sans rtti or exceptions) - because of its better code reuse. As part of this students could look at things like the Sun vnode layer as an example of OO factoring in C, and imagine how much cleaner it would read in C++. Then the education keeps building like this until it meets up with the higher level interpreters where it started. (And which are consistently used throughout the education to explore new concepts, like network protocols, transactions/atomicity, or RPC mechanisms.) I think the real issue ends up being how much someone can be taught in four or five short years. It's not much time.
No, I'm a programmer; I was referring to the fact that there are individuals working as programmers who only touch abstract Java code, and have little knowledge of how computers work.
This is really not such a bad thing. While the class in the story is a very elementary introduction to programming (for which all the various interpreted, easy to learn and use languages are great), the real problem domain for CS is, or should be, computing in itself. It should be about making computers easy to use for non-CS people so they can write programs in python, excel, Java, Pascal, or whatever their preference of the day is to implement business systems for their problem domains. No matter what the paradigm of the day is, there will need to be systems implemented to do these things: web servers, database servers, compilers, kernels, runtimes, etc don't just magically appear out of nowhere. And even though these paradigms shift around computers essentially work pretty much like they did 35 years ago, and the system software building blocks are the same. A queue is a queue, a scheduler a scheduler, atomic transactions are still atomic, etc. While some minor things change, the problem domain is the same: implementing programmable, efficient, reliable, useable systems. What's mainly changed is the problem domains of the user. But a computer is still a computer, and someone who did kernel work in 1985 could easily pick up Linux or a web server like Apache today. You still need C and assembler, still need to understand how the machine works, need to understand things like pipeline hazards, cache locality, bus arbitration, etc.
That said though, I'd be skeptical about anyone enrolling in a CS program without knowing how to program in e.g. python or Java. In fact, I'd assume they do and they're actually motivated by a desire to implement and understand runtime tools like this for themselves. But it's a good starting point to study algorithms, or at least the abstract part of them. An efficient implementation then clearly requires some degree of machine knowledge and tools that can leverage benefits while avoiding pitfalls. (It's a typical prototype to production step for this domain.)
Yes, why should anyone be concerned that their ability to afford food and heat in their declining years is dependent on the long-term stability of a system that can be radically damaged by a single mistyped letter?
I guess we're all just lucky this guy hit "b" and not "z".
Not only that, but a system where nobody even knows for sure why it even dropped in the first place! Maybe it was a typo? Maybe it was overseas? Maybe something else? Maybe our savings will be there when we retire? Maybe not?
How about if we start applying the same dumb blind belief to software engineering... Maybe it'll work? Or if it fails, lets design it so it's impossible to tell why! Let's just guess! Blind belief!
It just doesn't feel right to have something so flakey and ineptly designed so centrally positioned in our economy...
And when your 'Organic Only' store is carrying a hybrid/cross breed that occurred in nature (that no one is testing for) you still have consumed a GMO crop.
They DO random genetic testing you know. There are independent labs that test for GM markers, and distributors and retail chains that sell GM-free products do use them. That's not to say that a GM strain can't accidentally make it into the pipeline, obviously it's bound to happen. However, I personally am not too concerned with the occasional accident as much as the regular daily stuff.
I'd expect a libertarian to hold the view that if you contaminate your neighbors' soybeans or corn you're liable for cleanup and replanting, as well as medical care to people who ate it. This in turn would force growing to be geographically separated so as to prevent cross-pollination - or if that's not possible GM crops would be a commercial dead end. The liability litigation would simply bankrupt anyone who tried to grow it.
However, in the real world as opposed to libertarian utopia the best is probably to simply restrict growth of GM strains to laboratory settings.
All you "free market" enthusiasts out there, answer this question for me:
How would the unencumbered "free market" handle a problem like this?
I'm not a free market enthusiast, but even I can answer this: you take your business to a store that doesn't carry GM produce or products that contain it. My local Whole Foods store, for instance, is GM-free and predominantly organic.
If they had decided to start using 64-bit time on the 1st of January, 1970 none of these problems would have happened
The pattern:
/20[1-9][0-9]/ [if-unset: 2006]
##{ FH_DATE_PAST_20XX
header FH_DATE_PAST_20XX Date =~
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX
Will match 2010 no matter how many bits are used to keep time. This is a problem that has been know for years; it's a total embarrassment to OSS practices that it wasn't fixed before 1/1/10, before becoming critical. It's not based on a bad architectural decision, or even particularly bad code - it's just a typo where the fix wasn't pushed in a timely manner. I suspect a problem here is that open source development doesn't separate bug fixes from feature additions, which means non-critical fixes get backed up with features to be considered stable enough to ship. A critical fix can be spun separately (being backported to the current stable branch) - but this problem wasn't critical... yet...
Oh yes, they'd like us to believe that reverse engineering encryption is illegal. It is not.
Right you are. However, what is illegal is publically stating someone has committed illegal acts. Nohl should sue for slander.
It's so weird when reality looks like bad Photoshop.
They can't afford tabletop models anymore, so in this project they used paper cutouts on a black canvas.
If our Army is going to continue to make videogames, surely we can provide our citizens with Universal Single Payer Health Care....
The VA provides single-payer, single-provider, socialized, health care for the Army.
It's not high at all, $32M is peanuts for three mass market software products of this size and complexity. The more interesting question is why it has taken them so long to get where they are today. The answer to both questions lies in the fact that they work with enlisted personnel - for whom this may be their first job. They're cheap and enthusiastic, but slow.
Until we get a slick gui editor for javascript+svg animation, no.
In other words, we need GNU Ecmas.
As a CS student I think you should focus on product development, not IT. You absolutely should intern at a technology company whose main focus is products - and whose _customers_ may include IT departments. You won't be paid a whole lot, but the tasks you get will also be very simple, relatively speaking, and while they may be important, once taken care of you'll have plenty of time to poke around with whatever interests you. You may be asked to say add an option to a compiler, tweak a kernel build, or add data gathering and instrumentation - things that the other developers would like to have but don't find time to do themselves. If in the process you find something you think might make an interesting project by all means suggest it, chances are you'll get to go do it, unless it seems overly ambitious to the extreme.
Does the article discuss how much info each user leaked? I wouldn't be real surprised if the older users posted less info and were thus less concerned with privacy (It also wouldn't be shocking if they were simply less aware of it).
I guess at 45 I qualify as "older" in this context. I don't post personal details, or say things I don't want my business contacts to be aware of. FB serves the same purpose to me as a cocktail party - it's just a simple social function. I don't really care who wants to be my friend (which I view more as a 'live rolodex') - you never know who might be handy to know. I have about 300 friends on FB. My wife, who's a freelance writer and has to network as part of her business, has over 1500. It's just a tool, and like any other becomes what you make of it. I personally like it better than LinkedIn, which is too formal.
it ran as a screen saver
However it might have ran, it certainly didn't 'save screens.' Back in the day I saw many many CRTs with their phosphors permanently 'burned' by the SETI@Home display:
No kidding, I was always wondering how they got away with billing it as a screensaver. I left my PC powered on accidentally when I went on a four week trip in 2004 and came back to a 24" Sun CRT with SETI@HOME permanently burnt into the center. Screendestroyer is more like it.
So the woman gets paid and then the next day is robbed and killed by a roving gang or a warlord’s hunt and terminate party.
With that kind of money it should be easy to keep your own private army or buy protection from a warlord.
All out nuclear war would largely limit damage from the initial detonation and fallout to the northern hemisphere.
Perhaps, but if the northern hemisphere becomes uninhabitable a billion or so people will want to migrate south. The northerners will still be the most heavily armed in the world, have a long history of manufacturing excuses for wars that are thinly disguised land grabs, and aren't going to take no for an answer.
I practically never get sick and I have no known allergies. As a child, I dug in mud, I explored forests, I ate earth and worms and all kinds of crap. Perhaps that's the reason.
So did I - spent time in the local woods, swam in the lakes, jumped in every muddy puddle to be seen, played out in the rain, and whatnot. I'm still allergic to cats, some detergents, and natural rubber (latex, avocado). This was in the mid 70s, and people had allergies then just like today. It's just the bar was much higher and people didn't really consider it an allergy unless they were likely to go into shock or develop serious symptoms. A little spring sniffle caused by pollen wasn't really hay fever unless it caused breathing difficulties or made your eyes puff up so bad you couldn't see. Anything else just wasn't bothered with and parents would tell their kids, "yeah it's just a little spring pollen, now go to school."
I usually vote libertarian but I'd be all for banning smoking in public.
But what? There's nothing inconsistent about that - the air isn't your property to do with as you wish. It's held in common trust, so rules for its use (and abuse) is set through democratic political process.
I see how you come to that conclusion. But, it is false. No reason why the inputs and outputs can't be on separate buses and no reason why you can't have separate machines communicating over yet another bus or set of buses to build a pipeline.
Ah yes, that would be a pipelined design. I think that would work more efficiently than the original DDJ story's.
One version I found in my notes use a one instruction machine to implement the microcode for another machines.
I think too much significance is place on the "single instruction" aspect; the DDJ design is really "single instruction format". It clearly has multiple operations, and the destination address is more or less an opcode field. So it's more accurate to describe it as a single-instruction format machine. Each operation has its own dedicated destination register which can be used as a source for operations.
BTW, this kind of architecture makes it easy to add multiple execution units. With parallel execution and careful use of shared and private FUs and memories you can build a pretty damn powerful special purpose processor without a lot of hardware complexity.
All the execution units (aka co-processors in modern parlance) are still attached to a single bus, so theoretical max throughput is still one instruction per cycle. So this only makes sense if the CPs perform complex operations - like memory management, floating point, mul/div - or something of similar complexity. For the typical simple integer instruction that tends to dominate code it's no better than a microcoded processor - since now each normal instruction requires several cycles on the bus.
Compare this to a pipeline, where each step is what you'd consider a FU, but each one only needs to interface to the previous one, not counting the occasional clever bypass and special linkage. In a pipeline each FU can be fed an input in one cycle and provide an output in the next, something "FU"s (CPs actually) on a shared bus can't.
The other drawback is that anything that goes on the bus needs to implement a generic bus interface and its own internal sequencing logic. This doesn't come free. This is really just a CISC in silicon with exposed microcode, and it's pretty clear the author is thinking CISC all the way as can be witnessed by the stack operations. The typical RISC approach is to have a link register where the return address is placed on subroutine calls, so leaf functions don't have to push/pop it from the stack. Non-leaf functions start by saving the link register to the stack frame in the function prologue once space has been allocated for it.
ARMv6 and up, there's 'ldrex/strex', which perform a load/store of a word, with the store failing if a non-ldrex instruction or other core accessed the same cache line before the strex. Slightly more efficient, and all you need.
This is a lot like MIPS. And indeed, a RISC processor is pipelined rather than microcoded. In a microcoded design it's not really feasible to execute multiple instructions in parallel. ARM strays a little from the pure pipelined model in that it offers complex instructions like stm/ldm, mainly to make it easier to program and reduce code footprint - which is understandable given is origin as a home computer CPU (for the Acorn).
I think it would be cool to take RISC one step further where a single instruction is broken into 5-7 parts (or however deep the pipeline is), which each part controlling each step in the pipeline. But the assembler exposed a very traditional RISC instruction set similar to MIPS or Sparc, with a naked pipeline model - but then does initial instruction decode and generates pipeline steps instead. So while you might write "bal $a0", meaning store PC in LR, and A0 in PC, the assembler breaks this into pipeline controls over multiple instructions. Doing so would make it easier to fill delay slots and manage hazards, allowing the assembler to optimize the pipeline. Exposing a traditional RISC ISA would make porting a toolchain relatively easy, requiring only a version of gas with a pipeline optimizer. Of course, such a processor would require a slightly different pipeline, but it's somewhat plausible the changes would be mostly simplifications to reduce complexity.
I also can pay myself a 'reasonable' salary out of my total bill rate, that saves me $$$ in SS and medicare taxes. For example, say I bill out $100K. I pay myself a 'reasonable' salary of $40K. That means I only have to pay SS and medicare taxes on that $40K. The rest of the $60K falls through and EOY on my personal taxes, and I only pay regular state and federal taxes on that.
There's a whole cottage industry that helps create single shareholder-employee S corporations purely to reduce payroll taxes. It works - for now - BUT they also vastly oversell the benefits to people who are getting into deep water with limited experience. The IRS will reassess payroll taxes - and can do so at will. They look at your $40k and see how much it would cost to hire someone of a comparable ability, give you some benefit of doubt (say 5-10%), then send you a tax bill for the balance. So while you only make quarterly payments based on $40k, you may get a tax bill based on an additional $80k. $20k is what they may leave as a reasonable dividend payout. Or they could simply decide that $140k is a reasonable salary and what it would cost (including benefits and payroll taxes) to hire someone doing your job. So while you may save a little bit on taxes, it's by no means a slam dunk.
That wasn't the question. The question was, "Why shouldn't the First Sale doctrine apply to books and not to computer software."
It does. You can read the software as much as you like. You just can't make copies of it - like onto a computer, without a license to do so. Just like the book. But you can sit and read the bits of the disk as much as you wish. You can even give it to your friends for them to sit and read the bits until they get mortally bored with it.
And this is the fundamental difference between a book and software: reading the book is its principal use. It is in itself not meaningful with software.