Comment Prior art bitches (Score 0) 137
http://en.wikipedia.org/wiki/P...
Mickey Mouse was stolen to begin with. Fuck em.
http://en.wikipedia.org/wiki/P...
Mickey Mouse was stolen to begin with. Fuck em.
The article pointed to the very very very very very incomplete release notes for stuff after 3.5.
You wanted to link to the 3.5 release notes.
I once knew a guy who claimed to have built a computer operated grow room with a fail safe on the PC. He took a floppy disk a coated it in a friction sensitive flammable material. It was setup so if the computer rebooted than it would burn itself and the room down. Probably total bullshit but a good story.
No Oracle's contract is the fucking bomb, it did not stipulate a working end product. Oregon's attorneys should be paraded through the streets and have rotten fruit thrown at them.
Same reason that Regence BCBS blew $500 million on their REMAC project trying to replace IBM mainframes with PCs. They listened to ass-hat consultants and ignored the nerds. If your computer consultant arrives in a suit and a Lincoln Town Car DON'T FUCKING LISTEN TO HIM.
Portland is almost unique in the U.S. as we allow the combination of vices, all nude and liqueur in the same venue. Granted the stripper is going to be a PhD. candidate in women's studies with two kids but... TITTIES!
It's the other state to the north.
We should have gone with the Metal Toad linux offer and owned our own exchange.
Oh the horror! Imagine skills that transfer across Linux distributions! I won't LIVE in such a world!
Ahh, I see - I read that wrong. I thought it was the difference of "before vs. after" for the low-carb group.
The abstract lists significant % changes for the low-carb group - but doesn't show the numbers for the low-fat group. If the change is significant but tiny then it may as well be insignificant.
The whole "under 1024 is safe" is generally regarded for connecting *to* ports under 1024, not receiving connections from them.
It's only "safe" if you 1) trust that the machine to which you're connecting restricts the ability to bind to ports under 1024 (not guaranteed), and that the only people running processes on the machine in question are either trustworthy or are restricted from running programs that bind to those ports (not guaranteed), and that the system services you care about have ports under 1024 (not guaranteed).
And what guarantees that a "system service" (whatever that might mean) has a port under 1024? Perhaps a better scheme for determining whether to trust a service is called for here - one that would probably obviate the need for "privileged ports".
Yes, some services (NFS in particular) want to trust incoming connections from 1024 but they're in the minority.
One would hope that services that trust untrustworthy guarantees would be in the minority; in the best of all possible worlds, they would be completely non-existent.
If I was so inclined as to trust port numbers alone (and for the record, I don't trust incoming port numbers at all)
Good. Ideally, nobody would trust them, and claims such as "It prevents regular user programs from masquerading as system services, which usually sit below port 1024." would be treated as the uninteresting claims that they are.
The discussion was about adding more registers in a CISC architecture, and so CISC functionality is the context.
"CISC functionality" is the ability to execute a given CISC instruction set with acceptable performance. Transistors can be used in several different ways to achieve that, and you can choose to use fewer transistors in one place on a chip in favor of more transistors in another place, and if that choice means you still get better overall performance executing the same instruction set, that choice is a good one.
When you ask what "the same functionality means" that is absurd. You can't implement a subset of the functionality and still have the same functionality.
Again, as long as the full instruction set can be executed (even if some of it is executed by trap code), you don't have a subset. You may happen to execute some functions slower, and other functions faster, but if the net result is faster execution of the code actually run on the machine, you have a better implementation.
I'll put this in simpler terms. Smart people design CPUs and they don't add a bunch of registers even though that would be useful.
Smart people add registers iff they're sufficiently useful that it's worth either increasing the die size or taking transistors away from other functions.
The reason they don't do it is because of the additional chip real estate it would cost in an already over-taxed landscape, not because they are lazy or haven't though of the idea.
For existing architectures, the reason they don't do it is that it would require changes to the instruction format, which, for most instruction set architectures, would be a royal pain. For x86, they (AMD, to be specific) could and did add Yet Another Prefix to double the number of registers as the instruction set already had a tradition of adding prefixes. For ARM, they were already introducing a 64-bit variant of the instruction set, and didn't have to maintain binary compatibility. For, for example, System/3x0, you'd have to add prefixes to an instruction set lacking prefixes, or somehow use opcode bits to refer to additional registers. If somebody were to design a brand new CISC architecture (in an era where we're not designing many new instruction set architectures at all), they could design one with 32 GPRs.
Even if you kill all the below average people 50% of the remain people will be below average and you will be in both groups.
The AMD-64 architecture - is that also register limited?
With 16 GPRs, it has fewer registers than all the major RISC architectures other than 32-bit ARM, just as the 32-GPR System/3x0 (including its 64-bit z/Architecture version) does. It's less register-limited than x86, but that's not setting the bar very high. (Note that IBM recently added instructions to z/Architecture that do arithmetic on the upper 32 bits of the GPRs; that suggests that there's some register pressure with only 16 GPRs, although if they still have to make use of base registers, even with PC-relative branches, that might add some additional pressure that x86-64 doesn't have.)
Or did AMD toss something like 32-64 program accessible registers @ the problem?
No, they didn't; x86-64 has, as noted, only 16.
And if they did, would Intel have limited theirs?
Limited their what?
What this country needs is a good five cent microcomputer.
