They also own a LOT of Sco UnixWare boxes and a vast number of HP-UX machines. My bet would be that they're going to start by not renewing SCO licenses and see if they like what they get. It'll save cash, UnixWare can't be supported if all SCO can pay are the lawyers, and it doesn't put any of their Microsoft software at risk.
(They can't switch of Microsoft easily, anyway, as they switched to a pure Microsoft solution for application serving, security and externally-visible connections. This was back in 2003, so so. Fools.)
It's uncertain how the courts would take the contract part. I don't think Britain recognizes EULAs - they're not signed contracts and it requires a neutral third party as witness to constitute a binding Gentlemen's Agreement.
It's also my understanding that in Europe, APIs cannot be protected by copyright. There have been cases in Europe of one company suing another over API infringement, but the only ones I can think of are ones where the plaintiff lost.
Third, under British common law, the "reasonable man" defense is valid and does get used.
Having said that, inviting a lawsuit is stupid in the extreme. Particularly when your opponent has vastly more money than you and vastly more political clout than you. (Consider how many in the legal profession use Microsoft products. Now consider the impact of the proverbial "accident". Alternatively, consider the potential for performance bonuses to lawyers who choose the "right" side.) Even if it gets to the House of Lords - a possibility if there's serious money involved - you're dealing from a pack that is entirely comprised of wildcards. Law Lords have far greater independence than the US Supreme Court but also far less legal experience and have a range in IQs that map nicely onto a signed byte. It may even go on to the European Court of Human Rights, which is a whole other random number generator. Just because the main EU courts hate Microsoft's guts doesn't mean the ECHR will. They might do the reverse, precisely because of all the other rulings. You just can't tell.
So, you've a series of three, maybe four, totally random systems making legal decisions based on a type of contract whose existence is uncertain and whose non-existence may in fact create exactly the same offense by a different route, and where the lawyers and judges (and any potential jury) are almost guaranteed to be sufficiently ignorant of nomenclature that the issues will be utterly incomprehensible to any of them.
Legal aid is great for cutting court costs, but it doesn't supply the defendant with magic pixie dust or psychic reprogramming skills.
I'd argue that APIs should be enshrined in International Law as exempt from all IP regulations. An API is not a product - protect the product all you like, but the API is merely how two distinct products communicate and is not intrinsic to either one of them. Otherwise identical products can have any number of interfaces. Happens all the time.
However, and this is the important bit, my argument isn't worth an electron's nosebleed. What those random courts decide is the only thing that matters and those random courts are most likely to be persuaded by the better lawyers - which Microsoft will probably have/buy/steal/pwn. What's more, what those courts decide will determine (to a great extent) what all future courts in the UK will decide. Screwing this up doesn't affect one person, it affects the full sixty million. Backing off is cheap for one person, but losing will cost far too much for far too many. Pick your battles.
Maths co-processors... Yeah, I remember those. I wrote a Mandelbrot generator that manipulated the 8087 stack directly, so none of the floating-point values ever had to be transferred to/from main memory. All integers (for loops) were held in 8086 registers for the same reason. It was still slow, but it was a respectable slow.
IIT's maths co-processor could handle matrix arithmetic directly - it didn't have a simple 1D stack, but a 2D array you could process on. It was also roughly 10x faster than the Intel co-processor. For the time, this was a damn good product, and it's a pity they vanished. (Fractint even had specialized support for it.)
Support for protected mode - that was a waste. Yeesh. Switching between CPU modes is slow and rarely worth it. Forget the VIC20 - the PET 8096 supported up to 256 Kb of RAM (banked) and had offloading for all print and disk operations. Something that even modern ix86 systems do not generally have. The PetSpeed compiler, from Oxford Computing, was truly amazing - a superb four-pass compiler that could beat to a pulp any one-pass compile/one-pass link solution of the day. They did some amazing things that shouldn't have been possible on the PET in their demo, and their advertising was definitely risque. (I also know that at least one author reads Slashdot, so hi and many thanks.)
There is no guarantee that the brick will be supported under Linux. Unsupported bricks will fall and damage the Windows box, as outlined by the parent post. Furthermore, the brick is about the same size as a herring, if you scale Tux to the size of a real penguin. This may cause Linux indigestion.
The thing that scares me is that I've seen "reviews" in the regular and tech press that are so blatantly paid advertising as to be absurd, yet people actually take them as gospel truth. The Guardian newspaper in the UK is great in many ways, but don't bother with their tech section - it's almost 100% payola. I'm increasingly skeptical about the WSJ after seeing some of their "articles" as well. This isn't new - Computer & Video Games (aka Commodore & Vegetable Games) was notorious for highly questionable reviews. Nor is it limited to the low-end - I've seen plenty of falsely promoted high-end systems.
In the same way that payola for music is illegal (in the US, although actual prosecutions are almost non-existent), it would benefit the tech industry if payola "reviews" were outlawed. The problem there is that there were attempts to make non-payola reviews of tech articles illegal, by banning reviews that were not authorized by the manufacturer. Dunno if that ever passed, but it wouldn't surprise me. Nonetheless, without independent monitoring, the industry is nothing more than trickery and fakery. Why? Because those are so much easier and cheaper than actually doing any real work. If you make the money anyway, why not take the easier road?
An OS should provide the key services that require kernel privs, scheduling, hardware abstraction via drivers, filesystem support and resource allocation/protection. That is all the OS needs to do.
(Though that is not strictly true. You can divide these up into independent components that could run in parallel on today's processors. On a cluster, you could also drop components that aren't needed on a specific node.)
On a normal system, I see no reason why the OS kernel should take more than a megabyte or two. In a distributed system, you might be able to get away with half that on a minimal node, although the average would probably be in the 1-2 megs region. Anything beyond that would probably function at least as well in userspace.
With the increasing popularity of kernel bypass mechanisms for everything from graphics to networking to disk access, the number of kernel-based drivers needed on a high-performance system is probably much lower than for a cheap, low-end machine. Thus, the kernel size would be reduced accordingly. I'd say you'd be able to cut a quarter of the kernel (code and data) out with sufficient kernel bypassing. On a normal system, then, you'd be looking at 0.75 - 1.5 megs for the kernel. Of course, by doing kernel bypassing, you're implicitly doing some level of offloading, which trims the values down even further.
The next major eaters-of-RAM would be the system libraries (eg: glibc), standard environments (eg: X11) and standard toolkits (eg: OpenGL). Hardware implementations of OpenGL are almost standard, and physical X11 terminals provided hardware implementations of the X11 client-side, which means that most of that is (or could be) built onto the graphics card. Not sure what you could do about glibc, but I'd have thought there'd be a way of putting some of the core, essentially static, code into hardware.
Linux with X will run on 5 megabytes of RAM. Subtract 1 megabyte for the kernel and 1 for user applications, you get 3 for what absolutely has to be in RAM for the software to work. If you can shove a megabyte of this into hardware, this pulls your requirements down to 2 for the system. In practice, almost nothing can actually run at any decent speed on such a system, but we're figuring out what the underlying requirements are, not what the running requirements are.
The system requirements would seem to be 3 megabytes for a running minimal kernel, system libraries and basic GUI. This is your OS, in the modern sense, capable of running anything Linux can run. It's the minimal, fully functional system. Your applications will obviously take vastly more than that, but they can use anything above the basic minimum. Additional libraries, facilities, etc, will also take more memory, but if they're all in userspace and do kernel bypass, they're part of the applications and not part of the OS. They're also going to be faster.
Linux might easily start with 64 processes. Most won't be running at any given time, so you don't need more than a few critical data tables in RAM to be able to swap the process. The typical user is unlikely to be running more than four heavy applications at the same time, and of those, you're very unlikely to have more than two actually alive at a given time. If an active process is given 64 megs to play with, you need 128 megs for active stuff.
All in all, any complete distro (ie: distro software + hardware used) that needs more than 256 megs of RAM for a desktop must be doing something horribly wrong. It is simply not reasonable to use any more than that. Of course, most distros DO need more than that in practice, because machines are not designed to offload or perform kernel bypassing. The CPU does all the heavy lifting, and that's expensive on resources. It's not technically the fault of the software, it's the hardware that is at fault, but really even if the hardware was present, not many software distros can - as yet - take enough advantage of the capabilities to run on a minimal box.
(A lot of the software exists for Linux, it just isn't supplied by anyone or utilized by anything.)
With that many libraries of congress of data? Well, first there must be a New, Improved Mars - well, we've got to put all those Libraries of Congress somewhere.
A car engine is probably hotter than the ambient temperature of the air outside, by quite a lot. Not sure if a peltier device would be a practical heat pump for such a system, though.
It has long occurred to me that (chemical energy released) = (kinetic energy produced in engine) + (heat produced), under the law of conservation of energy, and that (initial momentum) = (momentum of moving components) + (momentum of particles) under the law of conservation of momentum. This means that the system as a whole must now satisfy both the equation for kinetic energy (ke = 0.5 * m * v^2) and that of momentum (momentum = m * v), as must each of the moving components of the engine and all individual particles. Any energy left over that is not accounted for by the components or particles is going to be released as heat and sound. Further, any collisions between the particles and the sides of the engine will not be "perfect" and will therefore convert kinetic energy into sound and heat.
The ideal would be to have an engine designed from the ground up for a very narrow range of conditions, such that the least possible energy is lost in the first place. That is bound to get you better results than trying to do single or double conversions on waste heat. You would then want far more sophisticated gearing, so that the engine will remain within the ideal conditions as much as physically possible.
(Cars with double transmissions are now becoming more common. Since each transmission works on gearing not provided by the other, so that there's always a smooth switchover, and since transmissions can have up to 6 gears these days, that gives you an effective 12-gear system if you do it right. Continuous gearing would be better, but that has never been made effective.)
Alternatively, do away with the whole existing design. It hasn't changed since the days of the Watt engine, except in the case of the rotary engine which nobody has been able to build in a way that is fuel-efficient. Even the rotary engine is an old design, though - 1930s. If you include the engine of the ancient Greeks, that makes for three fundamental designs in the past 2,500 years. It's hard to be impressed, particularly in a day and age of Beowulf and Mosix clusters that can simulate the internal workings of an engine at very high resolution in the basement of any geek with a handful of higher-end machines and a decent interconnect.
"The early ATI Linux driver had lacked essential functionality... not to mention a great deal of bugs."
I'd have thought lacking a great many bugs would be a good thing. (Yes, I know what was meant, but it's monday morning, I'm at work and I feel like pulling the legs off the English language.)
They have sufficiently large quantities of highly radioactive poison that they can afford to spread it over half of Europe in an effort to settle a single point of dispute. As motions go, the six-foot vertical displacement motion is rarely one that gets contested.
There is one very tenuous possibility - that the ship is altering ocean currents sufficiently to be detected with sufficient precision that the origin can be deduced by inference. The ocean's surface is the only thing you can see, ergo the only source of information he could be using. From there, you look at what can alter the surface, what can alter that, and so on.
Probability that this could be useful at very shallow depths, with objects whose size are far more significant in the scheme of things: Pretty good, but reverse computations of this kind are regarded as cutting-edge at the supercomputer fairs. The odds of seeing that kind of calculation being done, even at a near-trivial level, in the home is so close to zero you might as well watch the cartoons instead.
Probability of this working at the depths cited, with an object of negligible relative size, under probably highly unfavorable conditions: Definitely watch the cartoons. You'll have a far better chance of success.
Oh yes, you are absolutely right in saying that it's extremely rare. So rare that it's a motif used in some of the darker works of horror throughout history. The odds of the scenario you outline resulting in the fake mother being ok with the baby being killed are about on-par with the odds of someone carrying a highly contagious disease for prolonged periods of time in perfect incubation conditions and perfect contamination conditions without affecting a single individual. It's very very very rare, so unimaginably rare that it does hit the news when it happens.
I certainly don't disagree with you in any way on this, in terms of scenario. My point, I guess, is that the author of that fable was probably intending to shock, to keep it memorable, and that comparable conundrums that have no threats of violence have existed forever in society. So much so that culturally lies, greed and destructiveness are almost inseparable. Likewise, culture has identified truth, compassion and creativeness as a single, unified concept. These connections may have nothing to do with reality, they are merely ideas that have been built for tens of thousands of years. Being old doesn't make them special, being old merely means the ideas can draw on social security.
That's one reason it should not be taken as a literal event, but as a philosophical discourse on the association between honesty and compassion. (Another reason is that there is a statement that the events during the time of Solomon are documented elsewhere, but the book named no longer exists.)
Now, having said that, there have been many events in the news that are comparable in destructiveness and lethality to the Solomon story - by both real and fake mothers. There was a terrible story in the just last few days. Insanity places no bounds on behaviour - which is why I firmly believe mental health care should not be seen as something distinct or as something "tainted" by insurance agencies or by society, and why such care should be private (to eliminate privacy concerns) and safe (to eliminate the risk of "fixing" those things that make us individuals with a full range of emotions).
I'm not going to get into gory or gross details - the newspapers do a far better job of it anyway - but yes both real and false mothers have killed children to prevent them falling into someone else's hands, to save them from some other fate, or during an attempt to obtain them. There have usually been other reasons for men killing children, but Belgium is still investigating corruption amongst people in high authority involving such deaths. Britain has not recovered in forty years from Ian Brady and Myra Hindley. Their names are etched into the minds of the populace, carved into the psyche of the nation and so dramatically burned into culture as to change the whole of society in just a few months.
...King Solomon reckoned that one who was genuine would be compassionate that his technique worked. (This is independent of whether the event actually happened.) A derivative of this can be found in the puzzle of walking up to two people, one who will always lie and one who will always tell the truth. You need to know the answer to a yes/no question, but can only ask one person one question. What do you ask that will guarantee the right answer? (In the biblical case, substitute imposter for person who lies, and one who tells the truth for the real mother.)
Obviously, Solomon's situation - and solution - differed somewhat from the classical problem and answer in the details, but underlying it is the same basic idea, which is to force the liar to stay consistent and the honest person to change.
The USPO (and all other patent offices) rely on a high level of honesty, as they stand, but what if a variant of King Solomon's approach could be used, when rival claims exist? Have a way of putting the claims on the spot such that the real claimant will concede something before any false claimants would? Mind you, that might not work - current culture is designed to put self above all else, then both would rather rip the intellectual baby in half. It would only work with ideas developed by people who primarily care that the customers get the products. For example, I could easily see a humanitarian who develops a cure for some deadly disease preferring that the product be developed by someone else than not at all. That's not going to happen very often, though.
Nonetheless, I believe that such methods are inevitable, eventually. The system as it stands doesn't scale and frequently doesn't work well - if at all. Somebody will have to develop filtering techniques that allow false and fraudulent claims to be detected much more easily - and preferably by anyone who wants to apply those techniques. The patent pending scheme is supposedly so that problems can be found - well, that's all fine and good, if there's any way to find said problems. If a programmatic test can be found to do at least some of the filtering, then all the USPO needs is to distribute the appropriate BOINC clinet. Eventually, this must happen, as there's simply more work than can humanly be done in the time alloted and the system, the inventors and the innovators are suffering as a result.
Clearly, there is a demonstrable need for news sites to process dupes faster and in parallel with other dupes. The reason this one took so long is because there isn't a high-speed dupe instruction on the older generations of processors.
There's no certainty over which patches apply to which build case. Not all are guaranteed present for all builds. Fedora also uses its own code to apply the patches for reasons that are not altogether obvious. The patches are kept in the same directory as the source, cluttering the directory horribly and adding to the risk of name collisions if you're building different versions of the kernel. Because select patches are applied to the kernel, it becomes very difficult to massage other patches to fit within the Fedora scheme. This makes using Andrew Morton's patches, or some of the genuinely useful extensions out there such as web100, painfully tedious, as you have to find the right place to slide the patch in so that it has the least impact on subsequent patches AND is least impacted by the other patches.
(This is one reason I've never supplied broken-out patches for patchsets. It's one set, guaranteed consistent within itself, only one permutation exists, and therefore no alternatives need be considered in producing anything that extends it.)
One might ask why a person would want to add to Fedora Core's patch set. Well, if you want something that integrates nicely with Fedora Core, you will want to use the Fedora Core kernel plus whatever you want added on - be it wireless drivers, fixes for regressions, network optimizations/security, and so on.
Alternatively, you might be faced with a situation I ran into, where I needed to roll a kernel for a Fedora Core lookalike on a MIPS64 board. The vanilla kernel isn't predictable for the MIPS64 architecture, the only "safe" source is the repository used by the MIPS port developers. Now, getting the FC patches across to a non-standard kernel is absolutely horrible. You've no idea what has already been merged in, so have no idea which clashes are a product of the patch genuinely already being there versus simply clashing.
Diff/Patch are powerful tools for many things, but I'm no longer convinced they are sufficient when it comes to projects on this scale. Sure, it supports basic conditions, but there's not much basic about Linux (or X11 or GCC or glibc or any other gigantic piece of software). Maybe it's time to think of other ways to merge patches into code that can handle fuzzier, less distinct cases more cleanly.
Duh. If they're listening but can't hear, and visibility through the veil only works one way, it would have to be horribly thick and probably made of several layers of aluminium-coated wool.
Seems a pointless question - we already know the answer to that.:) I want to know if they're using infrared emitters as part of this - and whether I can use the Surface to keep my tea hot while I use a serious computer.
...why rootkit writers should ever be ahead of the game. First off, installing code into the kernel should be regulated such that rogue code can't gain all of the necessary rights. Yes, that means legit modules can't auto-install unless you have some multi-key system, such as having modules individually pre-approved, signed by the builder and countersigned by the system admin. Never said it would make your life easier. In fact, making things too easy for you makes it too easy for those you don't want to give access rights to.
Second, all modules should be exposed and visible at all times, along with the connections between modules. This is not hard. You have a hypervisor which doesn't do virtualization, rather it simply queries the OS on what the OS is currently doing. Why have something below the kernel? Because then it cannot be written to by the kernel. It is outside the kernel's memory space. It cannot be trapped, descheduled, replaced, modified or even sniffed by the OS or anything the OS is running. This gives you a covert channel to a monitoring tool that the rootkit cannot disable or interfere with. The OS merely needs to provide some sort of API that the hypervisor can use to supervise the kernel's activities and intercept the information needed to establish the covert channel with the monitoring tool.
Too complex? Ok, then how about a third solution: Have the compiler randomize the kernel's ABI. Totally. Absolutely zero predictability in how parameters are passed. The compiler just needs to make sure ALL calls to a specific function call that function the same way, whether the object is linked in or compiled as a module. It also has to make sure that out-of-tree builds also compile to the correct ordering for each function. Binary-only modules would need to be supplied with the source code for a glue layer that can map the binary's ABI with that of the kernel. Any unauthorized module will make calls that violate the ABI and therefore cannot stay running. They might crash the kernel, but that could be better than unauthorized and uncontrolled activity which might do far more damage.
Last, but not least, the kernel could support trusted computing modules and mandatory access controls for memory. It's the least secure, in some ways, but Trusted IRIX is pretty damn secure and I'd have some measure of faith in any integrity system that came close in design. (SGI released "Open B1" - OB1 - which was some of the code used to make IRIX as hard as it was. Dunno if anybody looked through the code for ideas - it wouldn't have mapped directly into Linux, but ideas are ideas and are OS-independent. Besides, OpenBSD at the time had no mandatory access control support. I don't know how far the other BSDs have got - I know there's some MAC and/or RBAC support in some, but are we talking basics or B1-equiv?)
Maybe a rootkit author could bypass all of these, but I doubt - seriously doubt - that it would be a trivial weekend exercise to bypass Trusted Computing or strong authentication/validation mechanisms.
So long as you read between the lines and not the text itself, you should be ok.
Fedora use a hacked kernel?
on
Fedora 7 Released
·
· Score: 3, Informative
Ummm.... The short answer is yes. The long answer is that there are a gigantic number of patches, but they seem to miss out on a lot of the key patches out there and I'm not impressed with some of the stuff they've included. In order to do a lot of useful things, I've got to roll my own kernel, but because the patchset provided with FC is so convoluted, I can't use any of their patches. Which means I lose all the functionality that actually is provided and actually is useful.
What I'd like is for Red Hat to build better diffs, develop some alternative scheme for merging in new code, or get as many of their patches rolled into the -mm tree as possible, then use the -mm tree exclusively. It may not be a true vanilla kernel, but at least -mm is openly maintained, heavily used, popular and actively folded into the mainstream.
The US considers the airewaves to be a commodity, as do other nations. Ergo, it is taxable.
It is also true that when two signals occupy the same frequency (as far as can be distinguished, and allowing for the fact that bandwidth is very literally the width of the radio band used), those signals WILL interfere with each other. This is not just true of signals of comparable strength, although that's when you start to really notice it for analog signals. For digital signals, see most of signals theory.
Now, arguably ALL electromagnetic signals will (eventually) pass through every point in the observable Universe. This means the tax has to either discriminatory or extremely small.
Personally, I do believe absolutely in the regulation of the airwaves - more so than the FCC, apparently, as I believe the radio astronomers should get first pick on any frequency that is vital to their science and replaceable by broadcasters. I also believe that there should be zero overlap between uses of the spectrum, so if X is allocated to the military, it SHOULD NOT be used by civilian devices and vice versa. In other words, if people won't play nicely in the radio sandpit, I believe it to be the responsibility of the appropriate authority to smack the b**** over the head with a clue-stick until they do. There are plenty of frequencies to meet all reasonable needs.
However, that is the exact antithesis of free trade and commodities, in which commodities can be bought and sold with minimal intervention, never mind strict quotas and optimizing for maximum gain to all parties. (Not most, all. None of this greater good for the greater number stuff, if it's not optimal for all then it's not optimal.) You cannot have systems both statically optimized and left to drift in the free market. The latter is good for many things and ends up with dynamic optimization in appropriate cases. Here, the needs and interests are all pre-defined and well known. The constraints on what you need to transmit a given amount of information in a given length of time is well-known. The absorption and reflective characteristics are also well-known and well-understood. The only direction the free market can go is towards inefficiency and waste.
I accept that airspace is "used" all over the planet by all radio signals, but if radio signals were managed, not marketed, there would be no issue with this. Only the markets can make the First Nations' claim valid.
Slashdot Mirror
(They can't switch of Microsoft easily, anyway, as they switched to a pure Microsoft solution for application serving, security and externally-visible connections. This was back in 2003, so so. Fools.)
In the UK, if he loses, he pays all court costs. That can be a substantial amount of money.
It's also my understanding that in Europe, APIs cannot be protected by copyright. There have been cases in Europe of one company suing another over API infringement, but the only ones I can think of are ones where the plaintiff lost.
Third, under British common law, the "reasonable man" defense is valid and does get used.
Having said that, inviting a lawsuit is stupid in the extreme. Particularly when your opponent has vastly more money than you and vastly more political clout than you. (Consider how many in the legal profession use Microsoft products. Now consider the impact of the proverbial "accident". Alternatively, consider the potential for performance bonuses to lawyers who choose the "right" side.) Even if it gets to the House of Lords - a possibility if there's serious money involved - you're dealing from a pack that is entirely comprised of wildcards. Law Lords have far greater independence than the US Supreme Court but also far less legal experience and have a range in IQs that map nicely onto a signed byte. It may even go on to the European Court of Human Rights, which is a whole other random number generator. Just because the main EU courts hate Microsoft's guts doesn't mean the ECHR will. They might do the reverse, precisely because of all the other rulings. You just can't tell.
So, you've a series of three, maybe four, totally random systems making legal decisions based on a type of contract whose existence is uncertain and whose non-existence may in fact create exactly the same offense by a different route, and where the lawyers and judges (and any potential jury) are almost guaranteed to be sufficiently ignorant of nomenclature that the issues will be utterly incomprehensible to any of them.
Legal aid is great for cutting court costs, but it doesn't supply the defendant with magic pixie dust or psychic reprogramming skills.
I'd argue that APIs should be enshrined in International Law as exempt from all IP regulations. An API is not a product - protect the product all you like, but the API is merely how two distinct products communicate and is not intrinsic to either one of them. Otherwise identical products can have any number of interfaces. Happens all the time.
However, and this is the important bit, my argument isn't worth an electron's nosebleed. What those random courts decide is the only thing that matters and those random courts are most likely to be persuaded by the better lawyers - which Microsoft will probably have/buy/steal/pwn. What's more, what those courts decide will determine (to a great extent) what all future courts in the UK will decide. Screwing this up doesn't affect one person, it affects the full sixty million. Backing off is cheap for one person, but losing will cost far too much for far too many. Pick your battles.
IIT's maths co-processor could handle matrix arithmetic directly - it didn't have a simple 1D stack, but a 2D array you could process on. It was also roughly 10x faster than the Intel co-processor. For the time, this was a damn good product, and it's a pity they vanished. (Fractint even had specialized support for it.)
Support for protected mode - that was a waste. Yeesh. Switching between CPU modes is slow and rarely worth it. Forget the VIC20 - the PET 8096 supported up to 256 Kb of RAM (banked) and had offloading for all print and disk operations. Something that even modern ix86 systems do not generally have. The PetSpeed compiler, from Oxford Computing, was truly amazing - a superb four-pass compiler that could beat to a pulp any one-pass compile/one-pass link solution of the day. They did some amazing things that shouldn't have been possible on the PET in their demo, and their advertising was definitely risque. (I also know that at least one author reads Slashdot, so hi and many thanks.)
There is no guarantee that the brick will be supported under Linux. Unsupported bricks will fall and damage the Windows box, as outlined by the parent post. Furthermore, the brick is about the same size as a herring, if you scale Tux to the size of a real penguin. This may cause Linux indigestion.
In the same way that payola for music is illegal (in the US, although actual prosecutions are almost non-existent), it would benefit the tech industry if payola "reviews" were outlawed. The problem there is that there were attempts to make non-payola reviews of tech articles illegal, by banning reviews that were not authorized by the manufacturer. Dunno if that ever passed, but it wouldn't surprise me. Nonetheless, without independent monitoring, the industry is nothing more than trickery and fakery. Why? Because those are so much easier and cheaper than actually doing any real work. If you make the money anyway, why not take the easier road?
(Though that is not strictly true. You can divide these up into independent components that could run in parallel on today's processors. On a cluster, you could also drop components that aren't needed on a specific node.)
On a normal system, I see no reason why the OS kernel should take more than a megabyte or two. In a distributed system, you might be able to get away with half that on a minimal node, although the average would probably be in the 1-2 megs region. Anything beyond that would probably function at least as well in userspace.
With the increasing popularity of kernel bypass mechanisms for everything from graphics to networking to disk access, the number of kernel-based drivers needed on a high-performance system is probably much lower than for a cheap, low-end machine. Thus, the kernel size would be reduced accordingly. I'd say you'd be able to cut a quarter of the kernel (code and data) out with sufficient kernel bypassing. On a normal system, then, you'd be looking at 0.75 - 1.5 megs for the kernel. Of course, by doing kernel bypassing, you're implicitly doing some level of offloading, which trims the values down even further.
The next major eaters-of-RAM would be the system libraries (eg: glibc), standard environments (eg: X11) and standard toolkits (eg: OpenGL). Hardware implementations of OpenGL are almost standard, and physical X11 terminals provided hardware implementations of the X11 client-side, which means that most of that is (or could be) built onto the graphics card. Not sure what you could do about glibc, but I'd have thought there'd be a way of putting some of the core, essentially static, code into hardware.
Linux with X will run on 5 megabytes of RAM. Subtract 1 megabyte for the kernel and 1 for user applications, you get 3 for what absolutely has to be in RAM for the software to work. If you can shove a megabyte of this into hardware, this pulls your requirements down to 2 for the system. In practice, almost nothing can actually run at any decent speed on such a system, but we're figuring out what the underlying requirements are, not what the running requirements are.
The system requirements would seem to be 3 megabytes for a running minimal kernel, system libraries and basic GUI. This is your OS, in the modern sense, capable of running anything Linux can run. It's the minimal, fully functional system. Your applications will obviously take vastly more than that, but they can use anything above the basic minimum. Additional libraries, facilities, etc, will also take more memory, but if they're all in userspace and do kernel bypass, they're part of the applications and not part of the OS. They're also going to be faster.
Linux might easily start with 64 processes. Most won't be running at any given time, so you don't need more than a few critical data tables in RAM to be able to swap the process. The typical user is unlikely to be running more than four heavy applications at the same time, and of those, you're very unlikely to have more than two actually alive at a given time. If an active process is given 64 megs to play with, you need 128 megs for active stuff.
All in all, any complete distro (ie: distro software + hardware used) that needs more than 256 megs of RAM for a desktop must be doing something horribly wrong. It is simply not reasonable to use any more than that. Of course, most distros DO need more than that in practice, because machines are not designed to offload or perform kernel bypassing. The CPU does all the heavy lifting, and that's expensive on resources. It's not technically the fault of the software, it's the hardware that is at fault, but really even if the hardware was present, not many software distros can - as yet - take enough advantage of the capabilities to run on a minimal box.
(A lot of the software exists for Linux, it just isn't supplied by anyone or utilized by anything.)
With that many libraries of congress of data? Well, first there must be a New, Improved Mars - well, we've got to put all those Libraries of Congress somewhere.
It has long occurred to me that (chemical energy released) = (kinetic energy produced in engine) + (heat produced), under the law of conservation of energy, and that (initial momentum) = (momentum of moving components) + (momentum of particles) under the law of conservation of momentum. This means that the system as a whole must now satisfy both the equation for kinetic energy (ke = 0.5 * m * v^2) and that of momentum (momentum = m * v), as must each of the moving components of the engine and all individual particles. Any energy left over that is not accounted for by the components or particles is going to be released as heat and sound. Further, any collisions between the particles and the sides of the engine will not be "perfect" and will therefore convert kinetic energy into sound and heat.
The ideal would be to have an engine designed from the ground up for a very narrow range of conditions, such that the least possible energy is lost in the first place. That is bound to get you better results than trying to do single or double conversions on waste heat. You would then want far more sophisticated gearing, so that the engine will remain within the ideal conditions as much as physically possible.
(Cars with double transmissions are now becoming more common. Since each transmission works on gearing not provided by the other, so that there's always a smooth switchover, and since transmissions can have up to 6 gears these days, that gives you an effective 12-gear system if you do it right. Continuous gearing would be better, but that has never been made effective.)
Alternatively, do away with the whole existing design. It hasn't changed since the days of the Watt engine, except in the case of the rotary engine which nobody has been able to build in a way that is fuel-efficient. Even the rotary engine is an old design, though - 1930s. If you include the engine of the ancient Greeks, that makes for three fundamental designs in the past 2,500 years. It's hard to be impressed, particularly in a day and age of Beowulf and Mosix clusters that can simulate the internal workings of an engine at very high resolution in the basement of any geek with a handful of higher-end machines and a decent interconnect.
I'd have thought lacking a great many bugs would be a good thing. (Yes, I know what was meant, but it's monday morning, I'm at work and I feel like pulling the legs off the English language.)
They have sufficiently large quantities of highly radioactive poison that they can afford to spread it over half of Europe in an effort to settle a single point of dispute. As motions go, the six-foot vertical displacement motion is rarely one that gets contested.
Probability that this could be useful at very shallow depths, with objects whose size are far more significant in the scheme of things: Pretty good, but reverse computations of this kind are regarded as cutting-edge at the supercomputer fairs. The odds of seeing that kind of calculation being done, even at a near-trivial level, in the home is so close to zero you might as well watch the cartoons instead.
Probability of this working at the depths cited, with an object of negligible relative size, under probably highly unfavorable conditions: Definitely watch the cartoons. You'll have a far better chance of success.
There's only one possible thing at that depth - Cthulhu!
I certainly don't disagree with you in any way on this, in terms of scenario. My point, I guess, is that the author of that fable was probably intending to shock, to keep it memorable, and that comparable conundrums that have no threats of violence have existed forever in society. So much so that culturally lies, greed and destructiveness are almost inseparable. Likewise, culture has identified truth, compassion and creativeness as a single, unified concept. These connections may have nothing to do with reality, they are merely ideas that have been built for tens of thousands of years. Being old doesn't make them special, being old merely means the ideas can draw on social security.
Now, having said that, there have been many events in the news that are comparable in destructiveness and lethality to the Solomon story - by both real and fake mothers. There was a terrible story in the just last few days. Insanity places no bounds on behaviour - which is why I firmly believe mental health care should not be seen as something distinct or as something "tainted" by insurance agencies or by society, and why such care should be private (to eliminate privacy concerns) and safe (to eliminate the risk of "fixing" those things that make us individuals with a full range of emotions).
I'm not going to get into gory or gross details - the newspapers do a far better job of it anyway - but yes both real and false mothers have killed children to prevent them falling into someone else's hands, to save them from some other fate, or during an attempt to obtain them. There have usually been other reasons for men killing children, but Belgium is still investigating corruption amongst people in high authority involving such deaths. Britain has not recovered in forty years from Ian Brady and Myra Hindley. Their names are etched into the minds of the populace, carved into the psyche of the nation and so dramatically burned into culture as to change the whole of society in just a few months.
Obviously, Solomon's situation - and solution - differed somewhat from the classical problem and answer in the details, but underlying it is the same basic idea, which is to force the liar to stay consistent and the honest person to change.
The USPO (and all other patent offices) rely on a high level of honesty, as they stand, but what if a variant of King Solomon's approach could be used, when rival claims exist? Have a way of putting the claims on the spot such that the real claimant will concede something before any false claimants would? Mind you, that might not work - current culture is designed to put self above all else, then both would rather rip the intellectual baby in half. It would only work with ideas developed by people who primarily care that the customers get the products. For example, I could easily see a humanitarian who develops a cure for some deadly disease preferring that the product be developed by someone else than not at all. That's not going to happen very often, though.
Nonetheless, I believe that such methods are inevitable, eventually. The system as it stands doesn't scale and frequently doesn't work well - if at all. Somebody will have to develop filtering techniques that allow false and fraudulent claims to be detected much more easily - and preferably by anyone who wants to apply those techniques. The patent pending scheme is supposedly so that problems can be found - well, that's all fine and good, if there's any way to find said problems. If a programmatic test can be found to do at least some of the filtering, then all the USPO needs is to distribute the appropriate BOINC clinet. Eventually, this must happen, as there's simply more work than can humanly be done in the time alloted and the system, the inventors and the innovators are suffering as a result.
Clearly, there is a demonstrable need for news sites to process dupes faster and in parallel with other dupes. The reason this one took so long is because there isn't a high-speed dupe instruction on the older generations of processors.
(This is one reason I've never supplied broken-out patches for patchsets. It's one set, guaranteed consistent within itself, only one permutation exists, and therefore no alternatives need be considered in producing anything that extends it.)
One might ask why a person would want to add to Fedora Core's patch set. Well, if you want something that integrates nicely with Fedora Core, you will want to use the Fedora Core kernel plus whatever you want added on - be it wireless drivers, fixes for regressions, network optimizations/security, and so on.
Alternatively, you might be faced with a situation I ran into, where I needed to roll a kernel for a Fedora Core lookalike on a MIPS64 board. The vanilla kernel isn't predictable for the MIPS64 architecture, the only "safe" source is the repository used by the MIPS port developers. Now, getting the FC patches across to a non-standard kernel is absolutely horrible. You've no idea what has already been merged in, so have no idea which clashes are a product of the patch genuinely already being there versus simply clashing.
Diff/Patch are powerful tools for many things, but I'm no longer convinced they are sufficient when it comes to projects on this scale. Sure, it supports basic conditions, but there's not much basic about Linux (or X11 or GCC or glibc or any other gigantic piece of software). Maybe it's time to think of other ways to merge patches into code that can handle fuzzier, less distinct cases more cleanly.
Duh. If they're listening but can't hear, and visibility through the veil only works one way, it would have to be horribly thick and probably made of several layers of aluminium-coated wool.
Seems a pointless question - we already know the answer to that. :) I want to know if they're using infrared emitters as part of this - and whether I can use the Surface to keep my tea hot while I use a serious computer.
Second, all modules should be exposed and visible at all times, along with the connections between modules. This is not hard. You have a hypervisor which doesn't do virtualization, rather it simply queries the OS on what the OS is currently doing. Why have something below the kernel? Because then it cannot be written to by the kernel. It is outside the kernel's memory space. It cannot be trapped, descheduled, replaced, modified or even sniffed by the OS or anything the OS is running. This gives you a covert channel to a monitoring tool that the rootkit cannot disable or interfere with. The OS merely needs to provide some sort of API that the hypervisor can use to supervise the kernel's activities and intercept the information needed to establish the covert channel with the monitoring tool.
Too complex? Ok, then how about a third solution: Have the compiler randomize the kernel's ABI. Totally. Absolutely zero predictability in how parameters are passed. The compiler just needs to make sure ALL calls to a specific function call that function the same way, whether the object is linked in or compiled as a module. It also has to make sure that out-of-tree builds also compile to the correct ordering for each function. Binary-only modules would need to be supplied with the source code for a glue layer that can map the binary's ABI with that of the kernel. Any unauthorized module will make calls that violate the ABI and therefore cannot stay running. They might crash the kernel, but that could be better than unauthorized and uncontrolled activity which might do far more damage.
Last, but not least, the kernel could support trusted computing modules and mandatory access controls for memory. It's the least secure, in some ways, but Trusted IRIX is pretty damn secure and I'd have some measure of faith in any integrity system that came close in design. (SGI released "Open B1" - OB1 - which was some of the code used to make IRIX as hard as it was. Dunno if anybody looked through the code for ideas - it wouldn't have mapped directly into Linux, but ideas are ideas and are OS-independent. Besides, OpenBSD at the time had no mandatory access control support. I don't know how far the other BSDs have got - I know there's some MAC and/or RBAC support in some, but are we talking basics or B1-equiv?)
Maybe a rootkit author could bypass all of these, but I doubt - seriously doubt - that it would be a trivial weekend exercise to bypass Trusted Computing or strong authentication/validation mechanisms.
So long as you read between the lines and not the text itself, you should be ok.
What I'd like is for Red Hat to build better diffs, develop some alternative scheme for merging in new code, or get as many of their patches rolled into the -mm tree as possible, then use the -mm tree exclusively. It may not be a true vanilla kernel, but at least -mm is openly maintained, heavily used, popular and actively folded into the mainstream.
...say that after falling IQ figures, the Sun is to be axed at the end of the silly season.
It is also true that when two signals occupy the same frequency (as far as can be distinguished, and allowing for the fact that bandwidth is very literally the width of the radio band used), those signals WILL interfere with each other. This is not just true of signals of comparable strength, although that's when you start to really notice it for analog signals. For digital signals, see most of signals theory.
Now, arguably ALL electromagnetic signals will (eventually) pass through every point in the observable Universe. This means the tax has to either discriminatory or extremely small.
Personally, I do believe absolutely in the regulation of the airwaves - more so than the FCC, apparently, as I believe the radio astronomers should get first pick on any frequency that is vital to their science and replaceable by broadcasters. I also believe that there should be zero overlap between uses of the spectrum, so if X is allocated to the military, it SHOULD NOT be used by civilian devices and vice versa. In other words, if people won't play nicely in the radio sandpit, I believe it to be the responsibility of the appropriate authority to smack the b**** over the head with a clue-stick until they do. There are plenty of frequencies to meet all reasonable needs.
However, that is the exact antithesis of free trade and commodities, in which commodities can be bought and sold with minimal intervention, never mind strict quotas and optimizing for maximum gain to all parties. (Not most, all. None of this greater good for the greater number stuff, if it's not optimal for all then it's not optimal.) You cannot have systems both statically optimized and left to drift in the free market. The latter is good for many things and ends up with dynamic optimization in appropriate cases. Here, the needs and interests are all pre-defined and well known. The constraints on what you need to transmit a given amount of information in a given length of time is well-known. The absorption and reflective characteristics are also well-known and well-understood. The only direction the free market can go is towards inefficiency and waste.
I accept that airspace is "used" all over the planet by all radio signals, but if radio signals were managed, not marketed, there would be no issue with this. Only the markets can make the First Nations' claim valid.