Volume, of course. Most everyone has abandoned slot 1 for socket A or socket 370 (which both seem to accomodate the same heat sinks), because manufacturing is cheaper and layout and mounting is easier.
My local screwdriver shop long since got rid of their slot 1 parts. Did they ever make fast (133MHz+ FSB) slot 1 boards?
The case must be right side up, since the top isn't flat. Clearly the power supply is mounted low (below the condenser) so its evaporated coolant doesn't have to flow "downhill". Maybe they mount the drives low and the board on the left so the power cables reach everything easily.
In a SF book (Spider Robinson?) a while back, a time-traveler from the near future observed the modern kitchen. "You have this stove to remove heat, and this refrigerator to add heat... and they're not connected?"
According to the manufacturer, they are using that thick side panel as a heat sink. Probably any chunk of aluminum (or other good heat conductor) with a large surface would do.
Only in the images--I presume that deters people who would embed images from his server in their reviews. In the text, his name only appears in his email address.
It's not either-or. We wouldn't ask them to abandon the browser-specific gimmickry (IMHO it's a foolish waste of effort, but I wouldn't say that to their face), just to think a little and make documents that aren't completely broken without support for them.
... or to sit on an overbroad patent that everyone infringes so that when someone else with an overbroad patent that everyone infringes comes after you, you can threaten to countersue and eventually agree to swap licenses.
This works for many big companies (which is part of the problem--innovators can't afford to do it) except against the leeches out there who don't infringe anything because they don't produce anything other than lawsuits.
It's incentive to publish. Clearly society comes out ahead by granting a twenty-year monopoly over a publically described invention that otherwise would have gone undiscovered for twenty years or more, because we have the description and might even have some limited access to use the invention in the meantime.
Where the gray areas start:
descriptions that aren't useful to people of ordinary skill in the art (the few patents I've tried to read are gibberish next to the worst RFCs)
inventions that would have been invented in the next twenty years without the patent
overbroad inventions that leave peers unable to compete at all, harming the free market
And of course denying the profession access to a technique anyone competent could have come up with in ten minutes is shockingly counterproductive.
That's enough to support six four-person households at median income. The fair price of labor is only what it takes to lure qualified people away from whatever else they could be doing, and there was no shortage of candidates I'd prefer over the current appointee.
I wouldn't doubt that all the money the PTO pulls in goes towards PTO-related activities, with some tax dollars thrown in for good measure.
I can't find anything more definitive than an old open letter, but I've been seeing unrefuted claims for a long time that not only is the PTO self-supporting (thus the steep fees that exclude small inventors) but Congress regularly swipes their surpluses for unrelated uses.
There is a misconception that it is the central duty of the PTO to form a blockade against granting patents.
Of course it's their central duty. Since "the Congress shall have power to promote the progress of science and useful arts", they can't delegate to the PTO the power to grant bad patents because they don't have it. What the PTO is getting away with is unconstitutional.
The PTO's purpose is to grant patents for a fee, and it's wholly suited to do so.
A notary public with a photocopier could do that. What do they do with all that labor and money, if not attempt to detect invalid patents?
If my boss offered me a bonus to rush through my work and give poor results I would still not do so
That particular measure of performance is more than an "incentive to the contrary". High throughput is allegedly how they stay on the job at all. Isn't it more constructive for the few conscientious workers to stick it out and do the best work permitted (under the circumstances) than to give up and leave the PTO with a staff comprised entirely of indifferent clods with rubber stamps?
That's exactly what "compelled to disclose your email address to Microsoft during the discovery process" means! If Lindows.com had refused to hand the info over, the judge would have sent the principals to jail for contempt.
If a TiVo faithfully plays back NTSC stereo like a VCR does, your receiver ought to be able to unmatrix Dolby Pro Logic if it was broadcast.
The only consumer-grade sources with Dolby Digital I can think of (since we can rule out TiVo ever getting away with recording content from a DVD) are broadcast or satellite HDTV, neither of which seem to be supported at all.
Why doesn't TiVo accept HDTV input? Isn't ATSC (the US HDTV standard) based on MPEG2, and wasn't it being able to skip encoding that made DirecTiVo so cheap?
I put redbook audio on a data CDRW, and it worked fine in my Saturn factory deck. I'm just starting to wean myself of the habit of carrying originals around.
IANAL, but from what I've read US patent law has very narrow infringement defenses for education (teaching yourself or others how the invention works) and research (improving upon it, possibly to get another patent) but not for ordinary use of the invention to it's intended purpose.
Unless end users can install and use their own modules (this is open implementation at the kernel level), a microkernel is no more than a mildly interesting implementation detail for the sysadmin. The moment you give access to malicious users, compile-time checks can't save you. You need some form of runtime barrier that either statically prevents unsafe code from being called or dynamically prevents unsafe instructions from executing.
The thing I like about static checking is that you don't need privileged access to special hardware to enforce it, and that means end users can easily avail themselves of it (this is why I mentioned JVM verifiers). Proof-carrying code sounds like a good optimization of them.
Shrinkwrap licenses are invalid because you don't see them until after the purchase. If they showed you the license at the counter and told you "by purchasing this product you indicate that you accept the terms of this contract," it would almost certainly be valid.
Without runtime barriers (either memory/bus privilege levels or JVM-like verification of loaded code) the sysadmin doesn't dare let any user install a module that isn't trusted by every user the system has ever had or will ever have. And having the source doesn't guarantee it's ever been perfectly (or even competently) audited for security....
Of course. Your microkernel (e.g., Mach) has an interface that's intentionally minimal, too little to run a normal userland. Your collection of servers (e.g., HURD) isn't ready. So you take a monolithic kernel (e.g., BSD), rip out stuff (like the scheduler) your microkernel does support, and run it as a single-server. This is how NeXTStep always worked, and the xMach folks seem to be continuing down this road.
When the only restriction is that you may not further restrict others, yes.
Where rights conflict, someone is going to lose, and our task is to decide which rights are most important (otherwise the weak lose by default).
Segment descriptors are cached, so a system that only ever uses at most one code segment and at most five data segments is significantly faster than a program that reloads segment registers as it runs. Swapping 4KiB pages is also simpler and less prone to fragmentation that swapping variable-size segments, especially since the hardware also already makes those checks and you have to do paging anyway for all those architectures that don't have IA32 segments. And then what do you do when 16384 independently securable objects aren't enough?
Re:Microkernels are a stupid idea.
on
Hurd: H2 CD Images
·
· Score: 3, Informative
If a module runs with limited privileges, security flaws in it can't be exploited to subvert the rest of the system, and sysadmins can safely allow normal users to install (or even develop) special-purpose modules for themselves without risk to any users who don't want to use those modules.
Certainly nobody could have done much with the Linux kernel without either the GNU userland (total reliance on which makes a GNU system) or a BSD userland, but why the HURD kernel deserves work when the Linux kernel is much farther along remains a valid question.
Personally, I think capabilities (securely running untrusted code) are the Next Big Thing in operating system innovation, because we've seen what a vulnerable environment we get if we have to delegate all our privileges to any random code we want to run. User-space drivers (a la HURD and Plan 9) seem to be a step towards that.
Slashdot Mirror
Volume, of course. Most everyone has abandoned slot 1 for socket A or socket 370 (which both seem to accomodate the same heat sinks), because manufacturing is cheaper and layout and mounting is easier.
My local screwdriver shop long since got rid of their slot 1 parts. Did they ever make fast (133MHz+ FSB) slot 1 boards?
The case must be right side up, since the top isn't flat. Clearly the power supply is mounted low (below the condenser) so its evaporated coolant doesn't have to flow "downhill". Maybe they mount the drives low and the board on the left so the power cables reach everything easily.
In a SF book (Spider Robinson?) a while back, a time-traveler from the near future observed the modern kitchen. "You have this stove to remove heat, and this refrigerator to add heat ... and they're not connected?"
According to the manufacturer, they are using that thick side panel as a heat sink. Probably any chunk of aluminum (or other good heat conductor) with a large surface would do.
Only in the images--I presume that deters people who would embed images from his server in their reviews. In the text, his name only appears in his email address.
It's not either-or. We wouldn't ask them to abandon the browser-specific gimmickry (IMHO it's a foolish waste of effort, but I wouldn't say that to their face), just to think a little and make documents that aren't completely broken without support for them.
... or to sit on an overbroad patent that everyone infringes so that when someone else with an overbroad patent that everyone infringes comes after you, you can threaten to countersue and eventually agree to swap licenses.
This works for many big companies (which is part of the problem--innovators can't afford to do it) except against the leeches out there who don't infringe anything because they don't produce anything other than lawsuits.
It's incentive to publish. Clearly society comes out ahead by granting a twenty-year monopoly over a publically described invention that otherwise would have gone undiscovered for twenty years or more, because we have the description and might even have some limited access to use the invention in the meantime.
Where the gray areas start:
And of course denying the profession access to a technique anyone competent could have come up with in ten minutes is shockingly counterproductive.
That's enough to support six four-person households at median income. The fair price of labor is only what it takes to lure qualified people away from whatever else they could be doing, and there was no shortage of candidates I'd prefer over the current appointee.
I can't find anything more definitive than an old open letter, but I've been seeing unrefuted claims for a long time that not only is the PTO self-supporting (thus the steep fees that exclude small inventors) but Congress regularly swipes their surpluses for unrelated uses.
Of course it's their central duty. Since "the Congress shall have power to promote the progress of science and useful arts", they can't delegate to the PTO the power to grant bad patents because they don't have it. What the PTO is getting away with is unconstitutional.
A notary public with a photocopier could do that. What do they do with all that labor and money, if not attempt to detect invalid patents?
That particular measure of performance is more than an "incentive to the contrary". High throughput is allegedly how they stay on the job at all. Isn't it more constructive for the few conscientious workers to stick it out and do the best work permitted (under the circumstances) than to give up and leave the PTO with a staff comprised entirely of indifferent clods with rubber stamps?
That's exactly what "compelled to disclose your email address to Microsoft during the discovery process" means! If Lindows.com had refused to hand the info over, the judge would have sent the principals to jail for contempt.
Sorry, the sites didn't mention that, and I moved and lost my southern exposure last year. So DirecTiVos have digital out?
If a TiVo faithfully plays back NTSC stereo like a VCR does, your receiver ought to be able to unmatrix Dolby Pro Logic if it was broadcast.
The only consumer-grade sources with Dolby Digital I can think of (since we can rule out TiVo ever getting away with recording content from a DVD) are broadcast or satellite HDTV, neither of which seem to be supported at all.
Why doesn't TiVo accept HDTV input? Isn't ATSC (the US HDTV standard) based on MPEG2, and wasn't it being able to skip encoding that made DirecTiVo so cheap?
Granting license for use of a trademark is possible. They can't ignore infringement, but they don't have to be ruthless about it.
I put redbook audio on a data CDRW, and it worked fine in my Saturn factory deck. I'm just starting to wean myself of the habit of carrying originals around.
IANAL, but from what I've read US patent law has very narrow infringement defenses for education (teaching yourself or others how the invention works) and research (improving upon it, possibly to get another patent) but not for ordinary use of the invention to it's intended purpose.
Unless end users can install and use their own modules (this is open implementation at the kernel level), a microkernel is no more than a mildly interesting implementation detail for the sysadmin. The moment you give access to malicious users, compile-time checks can't save you. You need some form of runtime barrier that either statically prevents unsafe code from being called or dynamically prevents unsafe instructions from executing.
The thing I like about static checking is that you don't need privileged access to special hardware to enforce it, and that means end users can easily avail themselves of it (this is why I mentioned JVM verifiers). Proof-carrying code sounds like a good optimization of them.
Shrinkwrap licenses are invalid because you don't see them until after the purchase. If they showed you the license at the counter and told you "by purchasing this product you indicate that you accept the terms of this contract," it would almost certainly be valid.
Without runtime barriers (either memory/bus privilege levels or JVM-like verification of loaded code) the sysadmin doesn't dare let any user install a module that isn't trusted by every user the system has ever had or will ever have. And having the source doesn't guarantee it's ever been perfectly (or even competently) audited for security....
Of course. Your microkernel (e.g., Mach) has an interface that's intentionally minimal, too little to run a normal userland. Your collection of servers (e.g., HURD) isn't ready. So you take a monolithic kernel (e.g., BSD), rip out stuff (like the scheduler) your microkernel does support, and run it as a single-server. This is how NeXTStep always worked, and the xMach folks seem to be continuing down this road.
When the only restriction is that you may not further restrict others, yes.
Where rights conflict, someone is going to lose, and our task is to decide which rights are most important (otherwise the weak lose by default).
Segment descriptors are cached, so a system that only ever uses at most one code segment and at most five data segments is significantly faster than a program that reloads segment registers as it runs. Swapping 4KiB pages is also simpler and less prone to fragmentation that swapping variable-size segments, especially since the hardware also already makes those checks and you have to do paging anyway for all those architectures that don't have IA32 segments. And then what do you do when 16384 independently securable objects aren't enough?
If a module runs with limited privileges, security flaws in it can't be exploited to subvert the rest of the system, and sysadmins can safely allow normal users to install (or even develop) special-purpose modules for themselves without risk to any users who don't want to use those modules.
Certainly nobody could have done much with the Linux kernel without either the GNU userland (total reliance on which makes a GNU system) or a BSD userland, but why the HURD kernel deserves work when the Linux kernel is much farther along remains a valid question.
Personally, I think capabilities (securely running untrusted code) are the Next Big Thing in operating system innovation, because we've seen what a vulnerable environment we get if we have to delegate all our privileges to any random code we want to run. User-space drivers (a la HURD and Plan 9) seem to be a step towards that.