Using Pi would actually be perfect for what I am thinking. At some point, we'd switch to a 3.0.x, then later on we'd move to 3.1.[0-4]... 3.1.4.[0-1] and so on. 3.0 would be the addition of the last major infrastructure you need. This would include multi-core support, regardless of whether the core is in the same chip, on the same board or in the same rack, but would also include the same level of transparency and flexibility for where any device hanging off any bus may be, and so on. That's the last set of truly deep changes you need to the Linux architecture to support the bulk of existing architectures and the bulk of new standards. I'd also see it where driver classes that have existed for a long time (such as the COMEDI control device driver package) and have close to proven stability are simply added. There is no justification in having them external and if you're aiming for a "solid" core, you absolutely don't want to have more such major API and structure packages in the complete wild than you absolutely have to. You can't reliably test or tune a system if it's not the system people are actually ending up with.
So why have a 3.1? If a 3.0 means all the core infrastructure you're likely to need for some time is in place, a 3.1 would mean all of the virtual interfaces and virtual APIs needed to make it practical to use the newer infrastructure components efficiently. The APIs needed for a physically contiguous physical machine will not necessarily be the same as the APIs needed for a logically contiguous virtual machine (where multiple virtual nodes on the same cluster may in fact be the same physical node, using something like Xen). This doesn't stop at clusters, by ANY means. If you have two Linux instances running on the same box and both are running SELinux, it should not be possible to use any shared resource to violate security labels - otherwise it's not really all that mandatory!
What else? Well, since PCI-e 2.1 will allow multiple physical nodes to control the same PCI bus, then there must be some way for the security labeling to be shared, or the labeling risks getting mangled. I suppose we could say SELinux cannot be used at the same time as PCI-e, but who the hell wants an OS that can only half-run on a platform?
This brings me to the other thing that 3.1 would need - to get the maximum number of permutations that either need to work together or have absolutely no reason to not work together - functioning on as many of the supported architectures as possible. Things shouldn't work on platform X and break on platform Y. There really isn't so much in the platform-specific code to explain why any component whatsoever should be unable to run on whatever it likes. And the few cases where platform-specific code is missing (TSC access was, at one point, a common problem), it's either not difficult to add or not difficult to dummy up.
Finally, there needs to be a cleaner and clearer implementation of real-time under Linux, particularly because of virtualization. With multiple OS' on a single box, you split real-time into two groups - real-time from the OS' perspective (ie: it is guaranteed a close-to-fixed N/M fraction of any given slice of the OS' logical time to run in) and real-time from the box' perspective (ie: it is guaranteed a close-to-fixed N/M fraction of any given slice of the box' physical time to run in). Each type of real-time will have distinct requirements and there must be some way of clearly stating the maximum permitted variance for both any individual instance and for the run as a whole. These will mean API changes as well as infrastructure changes to the scheduler.
Ok, so we've got all of these large components welded into place and have a 3.1.3.x version that has stabilized and has eliminated bugs that would require major structural changes - and preferably more besides. Your 3.1.4.0.x version becomes a snapshot at which heavy-duty changes are unlikely. You then cycle up through the inevitable brown-paper-bag bugs to 3.1.4.1.0, whic
We can't have a 2.7, as that's subject to litigation from SCO, and we can't just stick with 2.6 forever, or we might as well drop the 2.6 the way the Great Emacs Renumbering did with unused digits in its version.
Seriously, 1.0 was considered "feature complete" at the time of release, and there are some major architectural changes which will be required in order to improve scalability across multi-core as well as SMP systems, not to mention some fairly major pieces of work that are still under development which will need to be merged fully at some point (DAPL being one of the bigger). With the growth in the cluster market, I would also expect some meta-structure to go in to support the basic concepts. Even PCI-e 2.1 support is going to have a serious impact, due to the changes introduced in it.
If I was in Linus' shoes, I'd be pushing for these big infrastructure components to be readied and maybe placed in the -mm tree at this point. Once they're ready for the big time - which might take a while - I'd migrate them into the main tree and wait three or four cycles for last-minute bugs to settle down, then flip to 3.0 to mark the first of a generation of kernels that are keeping pace with the curve. I'd reserve 4.0 for when Linux is not only stable for mainstream use but defines the curve for OS development. I think everyone on Slashdot is at least aware of the research into new hardware technologies, new OS technologies and so on, so I don't think anyone seriously believes that Linux won't undergo more fundamental changes in its life.
Obviously, I am not Linus and he gets to do what he wants, whether I - or anyone else - would agree with his beliefs or not. However, his reluctance to flip digits is not new - I remember when kernels had a letter at the end to mark the sub-sub-version and it had to go into 2 letters because Linus ran out of alphabet. I also remember the first time sub-sub-version numbers ran into the hundreds. On both occasions, there was gigantic frustration with the absurdity. I guess he's forgotten the problems caused, or something.
The screen is inherently an output-only device, and framebuffers allow you to direct output from an application to the screen in a mixed text-and-graphics mode. To me, that makes it as much a UI as anything else. It's not fancy, but neither was the mixed mode for the BBC Micro or the Apple IIe. If those were UIs, then so's a framebuffer.
It depends. I would suggest using 1d4 for every 1.544 MB/s (equiv to a T1) that a line can carry to determine its XP value, as the faster a line is, the harder it will be to hit.
Although the Liberal Democrats in Britain are a relatively minor party in government, the opposition (the party that came in second in the general election) cannot win a vote without the help of the Liberal Democrats. Likewise, the party in power needs only a handful of Liberal Democrats to side with them to guarantee winning a vote, even allowing for party defections. Thus, both sides regard the Liberal Democrats as a little bit of a wildcard. It can't do much on its own, but can wield quite a bit of influence.
(It is also worth noting that the Lib Dems control a very large number of local authorities. Pissing them off can therefore have interesting consequences. It would be most unfortunate if a new sewer had to be installed in the road... right outside an MP's house... Terrible... Don't know how that could have happened...)
Both the opposition and the third party have other weapons that do not exist in America. Either can call for a motion of no confidence, in which the Prime Minister MUST appear to answer questions. As indeed they must for Parliamentary Question Time. Although it has not been used this way for years, it used to be standard practice to use no confidence motions to force the other party to turn up for important debates, as the Prime Minister must resign if the motion passes. It is vital to that party that it can guarantee as large a majority as possible. Question Time is also important, as it creates a much greater sense of accountability. It's not perfect, but it gets better answers than subpoenas seem to be in America.
Possibly. The article was... unclear. Even there, though, one should avoid creating new categories unless there is a scientific or budgetary reason for doing so. Is it possible, for example, that interstellar winds were simply very strong at the time the star went supernova and thus the debris simply got blasted clear of it? To show that, you'd want to estimate the age, determine how far the debris could have traveled and then look to see if there are small pockets of unusually dense dust/gas in deep space.
The benefit of this is that we don't have to imagine any new processes or classes of stellar object. All we have to be able to imagine is that the winds within the galaxy are potentially highly variable. It just seems as though this would be an easier, simpler explanation. It just wouldn't be an explanation that would get media coverage or additional grant funding.
Let's face it, a pulsar shoots incredibly focussed beams of radiation from the poles and the poles alone. It is so incredibly focussed that even though all the object is doing is spinning off-axis by a small amount, we only see clearly-defined pulses. All it requires is that we're never inside that very narrow cone that gets a signal, and we would observe something from which we would never get any pulses.
There are also other variants of these objects - magnetars, for example - that are, if not well-known, then at least recognized and classified.
To decide this could be something totally new is an interesting decision but nothing in the press release is telling me why they have made that specific decision over, say, merely seeing a regular pulsar at too great an angle to ever see the pulses.
Yes, the heat physics applies, which is why I believe that a two-layer system that is arranged back-to-back (so both hot surfaces are also outward surfaces) and aligned vertically on the motherboard is the only way you'll ever fix the heat problem with any reliability. Now, there have also been articles about using thin films of liquid for cooling, but I'm not sure I'd trust such a system. The vertical arrangement should function just as well as a single hot surface facing outwards, as the inwards surface in neither case gets meaningful cooling so is presumably not much of a factor.
Cost-effective is the key to this, though. This is where multi-core systems matter. With a multi-core system, you have essentially one shared I/O bus through which all data is delivered. On the MIPS chips, this I/O bus (the Z bus) was also used for all CPU-to-CPU traffic, I don't know if this is the case on 80x86 systems. Essentially, though, you have a severe bottleneck.
Any N-way CPU must check every core for requests/posts - probably in a round-robin fashion - and then manage which core has the lock on the bus at any given time. The more cores you have, the more likely two cores will want the bus at the same time, the greater the net latency of the system. Eventually, adding more cores will actually slow the system down. In most SMP and multi-core systems, there are bottlenecks somewhere in the arrangement that will pretty much die above 16 cores.
So, to build a 64-way system that is even equal in performance to a 16-way system, you must either have an MxN-way system where each N-way CPU is wholly independent from the M-1 other CPUs, even though they are on the same silicon (essentially operating at the level of a cluster rather than a multi-core chip) OR you must ramp up the bus speed by a factor of 16 to handle the extra traffic and overheads.
From an architectural standpoint, a cluster is dirt-cheap compared to increasing bus speeds by that amount. Running lines from wafer to wafer is not cheap. It is very expensive, as you pointed out. BUT it only has to be cheaper than building a 48 gigahertz I/O bus in order to be cost-effective for the same level of performance per unit volume occupied by the system.
(Volume is important, as the cheapest solution of all per unit of performance is to build a giant heterogeneous cluster such that traffic never needs to go much beyond nearest neighbor, and have a butterfly network linking the nodes together. It will take up a lot more room than a single-stack or double-stack CPU - indeed, it will likely take up a room in many cases - but you will never build a CPU that can outperform such a cluster for the same price, simply because costs increase superlinearly or exponentially with the speed of an individual component, but are linearly divisible across multiple components.)
Oh, well that one's easy to solve. Lazy and incompetent scientists and archaeologists get to provide organic supports within the concrete structures. Everything else gets sorted out by Darwinian mechanics.
Well, some hieroglyphs. There are a good few hundred languages from the days of writing on stone or in clay that cannot be deciphered and quite likely never will be. I find the study of ancient languages fascinating, as they were never intended to be DRMed - uhh, unreadable, but they have become so. At the present time, nobody has successfully used computers to assist in decoding such languages except in the limited sense of counting sign combinations. This seems like a superb application, but it is also an unsolved application. Nobody, nobody at all, knows how.
When it comes to old technologies, some things are superb and some things have proven a disaster. Floppies didn't start with the 5.25" - the 8" was older and is even less readable. Long before floppies, you had core memory. Good for 100+ years! But in less than half that time, I doubt there are many systems that could actually read the damn thing without wiping it. (Core was destructive on read, so you had to perform a write for every read into the correct address space.)
On ancient technology, more than one archaeological site has been utterly destroyed - partially or totally unmapped and unstudied - because some country or other wanted to build a dam. Water is important, sure, but you can collect water in any number of ways, and even if the dam is imperative, it'll take years to decades to build. Allowing scientists a few months to collect irreplaceable data isn't going to kill anyone or anything. Denying them does kill our chances of understanding the past. We only have one history, once it's gone, it's gone. It is, sadly, very easy to destroy and politicians have done much to destroy it.
If you have a mini-pipeline running to each processing element, and an instruction ID, then scheduling issues may be reduced somewhat as you can then not only execute whole instructions out of sequence, but fragments of instruction out of sequence between instructions. The smaller the atomic unit you are working with, the less effort is required to achieve equal or better packing.
I also prefer the idea of virtual cores over physical cores for the same reason. You can "steal" unused processing elements from a virtual core, therefore you can improve the total amount of processing elements in active use and therefore the efficiency and parallelism. The pipelines to each processing element would only need to be deep enough to produce an effective illusion of having that many physical cores.
What do you do when the task is already reduced to the simplest level? Well, you want to shorten the critical path by selecting different processing elements where a choice is available. You want to have the cache profile what is being used, so that retention is based on experience. (This allows you to exceed the theoretical best performance of a dumb caching system.) You want to break things down to a finer level of granularity (if you can) because that may provide opportunities for superior caching and superior parallelizing.
How do you tune and load-balance when the hardware is at 100%? Well, you want to know if it's the ideal 100%. Better profiling of cache activity may reduce off-chip I/O by avoiding dropping items you will shortly need. Since hotter chips are more likely to be subject to errors, and errors generate latency, tuning may involve better cooling. Since the internal bandwidth is greater than the off-chip bandwidth, and since you are limited by the critical path, your true performance requires you to tune cache I/O and CPU usage in parallel. This can mean that you get superior performance by detuning the processor elements so that the I/O can be more evenly distributed and therefore superior.
I don't think much extra scheduling hardware is needed, beyond some very simple profiling work and some basic multi-way analysis.
However, I don't think any of this is the best way to improve CPUs. The best way, IMHO, is to build a two-layer chip - one layer being RAM, the other being the CPU cores - where the RAM is running at 100% of the speed of the cores. Eliminate the outer level of cache and eliminate most of the I/O saturation issues. Sure, it'd be more expensive than a conventional design. At least, initially. All new designs are more expensive. And we're also talking about more expensive than a slower system, don't forget. By accelerating RAM to CPU speeds, eliminating a layer of pipelining and caching, and wiring each core to RAM pretty much directly, the ability for each core to do work is independent of the number of cores, provided writes are to different parts of RAM. When everything is funneled into a narrow pipeline, it's no different from funneling a hundred junctions onto a narrow Interstate. You will suffer horribly. A single CPU with multiple cores generally hasn't the I/O capacity to handle all cores performing I/O at once. If you want to avoid more complicated scheduling - needed to maximize total throughput - then you need to increase the I/O capacity and there is no easier way to do that than to have a dedicated I/O connection per core in addition to any core-to-core lines.
Long, fast, parallel - pick two. If fast and parallel are paramount, then you need very very short connections, which means you want two back-to-back wafers with lines running between them. The distances can't be any shorter than that, without having the cores or processing elements too far apart, with all the problems that causes.
Nothing unusual for Intel. Transmeta's work on efficiency was bettered by Intel suspiciously quickly and easily. More than a few developments have "appeared" shortly after the competition bettered them in something. There are only two exceptions that I know of. The first was maths co-processing, in which Intel lagged the competition on both price AND performance until they eliminated the entire niche by producing the 486DX. The second was the 32/64 processor architecture. In both cases, it took Intel many years to do anything.
Based on those examples, I would say that genuine progress by Intel is slow, and that any sudden shifts are really the result of having already produced the technology and holding it back.
Yes, but which type of birch? To quote Wikipedia, "Birch is the name of any tree of the genus Betula (Bé-tu-la), in the family Betulaceae, closely related to the beech/oak family, Fagaceae". The article there goes on to list 32 genetically distinct types of birch tree. I can't see how they'd produce identical chewing gum and I seriously doubt that every single variety would even be safe.
All you "need" to light up fiber is a switch or router at both ends that support optical connections. If you want to have a decent - but no gotta-write-home - connection, then you can expect the total cost to be about $4,000 plus the cost of leasing/buying the installed line. Less, if you buy the devices off eBay, which usually carries optical routers and optical switches.
On the other end of the spectrum - literally - you have Dense Wavelength Division Multiplexing devices that can stack up as many parallel transmissions on a single fiber as the fiber has optical quality to carry. This is where you can get into the realms of terabits per second and even petabits per second. This doesn't come cheap. If you want high-end gear, you're looking at $150,000 total. Very high end, you can probably add a zero or two to that, but getting the actual prices becomes hard.
Typical gear for lighting up dark fiber is around ten grand. That is more than enough to get the hardware needed to build a good metronet or a fairly decent city-to-city link.
Ten thousand is a bit much for a student science project, but most cities waste more than that each year just to use up their budgets to avoid cuts the year after. If you put that wastage into infrastructure, gigabit links to private homes would be entirely within reach.
You're correct, and it would cost very little to light up dark fibre as it is already set up and essentially just needs plugging in. There is an alternative infrastructure, Internet 2, which is much bragged about but isn't terribly impressive.
Now, if you were to ask me what I would like, I'd like a mesh city-to-city network that boasted petabit speeds - well within the highest speed recorded for thousand-mile links - and where within each city there was a metro-wide network that stepped the speeds downwards at the smaller scales. Each block would then be provided with a set of taps and it would be up to the owners of the buildings on that block on how to handle the distribution. A rural area would be a spur off the nearest metro-area network and would be treated as N many city blocks, depending on population. Again, the line in would be provided but locals take care of the last segment.
(This is not dissimilar to the current ISP notion of the "last mile", except I would rather that those using it have control over it. The "last mile" is the part ISPs care least about, because that's one connection and therefore the smallest unit of income. It's far far better if those who place greatest value in it have greatest say in it.)
Where does this leave ISPs, though? Well, cable is usually delivered by having stages of taps and so we know this model works. Meshes are used by some ISPs already - Telus in Canada is not a good example, but they do at least illustrate that I'm not talking mom-and-pop shops here. The charging mechanism for the Internet - by bandwidth - is best suited to hierarchies of provider, each working at different speeds, rather than conglomerates offering everything, as it distributes the costs out better.
What about freedom to choose ISP? Who gives a f? When you buy water from a different company or electricity from a different company, you don't get new plumbing or wiring. You don't get a different product. You merely get a bill with a different letterhead. It's like having all these brand names in stores, only to discover that the products all come from the same factory. You don't have this "choice", unless you can choose something different.
With the Internet, things are no different. 90% of the connection is common, no matter who you use as a provider. If you use DSL, virtually all of the phone line is common, no matter who you use as the provider. When you pick a provider, you are picking one - maybe two - routers, which you can pretty much guarantee are either Juniper or Cisco, and the IQ of the person maintaining them. Since both are relatively easy to maintain, this need not be very high in order to obtain perfectly reasonable service. Which, in some cases, is just as well.
If you have no real choice anyway, what possible difference can it make if all the ISPs use the same infrastructure and use the same billing structure as all the other vendors you buy from? At least there'll be fewer components in the system (so giving you greater reliability) and more paths to reach the destination (so again giving you greater reliability).
Of course, the Government could just create a Department of Por^H^H^HInformation Technology and run the whole thing centrally. If done correctly, it would eliminate the middle men and reduce the inevitable squabbling over where the taps will go. Privacy would be unaffected, as we know they've got sniffers in AT&T and probably other providers, and in fact inter-Departmental rivalry would probably protect it a whole lot more than the corporate sector has.
FidoNet? Hell, when I first got onto the Internet, I was hooked up through direct access to a global network of computers linked by satellite, thanks to the NSF and the EU. International Packet Switch Stream was no FidoNet. We are talking self-repairing connections, true direct access to anywhere in the world, and raw power you would not believe. Dial-up was 1200/75 or 300/300, direct lines were 9600 or faster. This is back in friggin 1985!
Graphical interfaces? Yes. CAS Online had a full sentence parser hooked up to a SQL database that could churn out full 3D rotating molecules, research papers, the works. When I compare it to the web of today, I despair. The best commercial sites run at a fraction of the speed, have a far more convoluted interface, and true 3D over the web has become more mythology than technology.
But was this available to the masses? Sure! Anyone could sign up for an IPSS account. It wasn't cheap, but it wasn't bank-breaking either. All you needed was a computer and a modem.
So what was the problem? There was no problem, by and large. The uptake of IPSS - particularly after MUD1 got mentioned in PCW and Practical Computing - was substantial. Far more people used it than used PRESTEL or other such online services.
FidoNet - well, FidoNet was treated as something dirty and inferior. Which, frankly, it was. You couldn't log onto computers anywhere in the world over FidoNet. You couldn't get genuine 2D or 3D vector or bitmapped graphics through FidoNet. As a bulletin board, it was considered vastly inferior to TBBS (The Bread Board System) which was a very popular system in Britain in the 80s. I can't think of a single site in Britain on any of the BBS lists published by mainstream sources that were FidoNet.
Oh, as for being elitist - yes, I guess I am. I most certainly do not believe in compromising quality for quantity. I also believe that you need not compromise quantity for quality, except maybe at the start. I believe in the inherent superiority of all solutions that give everything and compromise nothing. I believe in the inherent inferiority of those who deprive others of either quality or quantity (or both) for the sake of money they will never see, never need, never use and never value except insofar as it is a score in a game they play with other inferior-types.
No, not all people who make money fall into this category. The point is, money has no intrinsic meaning or worth. It only has value insofar as it enables you to do something. If you're making so much money that nothing further can be enabled, then yes I will look down on you - and have good reason to, too. If you let it rot in worth and enable nothing, simply to claim a better high score on a league table somewhere, I'd consider myself so far above that I'd need a telescope to look down that far. These are the attitudes of ISPs and backbone providers, and far too many content providers. As a result, I sneer at their pathetic greed and - to quote a Python - fart in their general direction.
The award for "Most Ignorant Righteous Asshat of the Year" goes to...
...all of those who thought private enterprise would be worth a damn when it comes to high cost, high maintenance, low profit infrastructure. However, runner-up prize goes to the granny in Europe who has a hundred gigabit link to the Internet and isn't hosting a CPAN mirror.
The NSF was stupid enough to hand control over to Sprint, AT&T and the like. The more commercial the Internet has become, the more commercials the Internet carries. It is interesting that spam was invented and promoted by a couple of lawyers. Interesting because it is inevitable that as the signal/noise ratio deteriorates, those attempting to generate self-promoting noise MUST amplify that noise, deteriorating the ratio further. The lawyers did not create free advertising, as they claimed, but rather very cost-effective self-destruction.
(At this point, there would be a good case for blocking all e-mail traffic on the Internet backbone for a week, then on the assumption that anything still sending after the first day is a zombie, simply banning the entire offending network until it cleans up. Sure, it would cause chaos, but the economic and personal damage done by a week's shutdown would be minuscule compared to the expense paid on a continual basis because of spammers and malware.)
There are plenty of proxies for Linux (and Windows) that'll present their own browser IDs. This has the advantage that if you're running a home network, all machines on the home network will appear the same way. If the proxy is caching, it will also reduce the bandwidth requirements. That can be important, when downloading free po^H^Hsoftware.
...I'd quite like it if they used weather symbols to indicate the probability of adoption and timeframe, and the degree of concern over it. For example, sun mixed with cloud would indicate prospect of being adopted in near future. Lightning would indicate that it'd be adopted over the dead bodies of 50% or more of the list.
The seating must be in the Complex domain, and for the output to generate the necessary synchrotron tachyon, the banana must be entangled with the fish in the tailpipe, as postulated by Minsky space.
Slashdot Mirror
Muscle emulation can only virtually break arms.
It might be Quaked instead, or Wolfensteined. These days, there's a whole range of possible catastrophes - no need to limit yourself to one.
So why have a 3.1? If a 3.0 means all the core infrastructure you're likely to need for some time is in place, a 3.1 would mean all of the virtual interfaces and virtual APIs needed to make it practical to use the newer infrastructure components efficiently. The APIs needed for a physically contiguous physical machine will not necessarily be the same as the APIs needed for a logically contiguous virtual machine (where multiple virtual nodes on the same cluster may in fact be the same physical node, using something like Xen). This doesn't stop at clusters, by ANY means. If you have two Linux instances running on the same box and both are running SELinux, it should not be possible to use any shared resource to violate security labels - otherwise it's not really all that mandatory!
What else? Well, since PCI-e 2.1 will allow multiple physical nodes to control the same PCI bus, then there must be some way for the security labeling to be shared, or the labeling risks getting mangled. I suppose we could say SELinux cannot be used at the same time as PCI-e, but who the hell wants an OS that can only half-run on a platform?
This brings me to the other thing that 3.1 would need - to get the maximum number of permutations that either need to work together or have absolutely no reason to not work together - functioning on as many of the supported architectures as possible. Things shouldn't work on platform X and break on platform Y. There really isn't so much in the platform-specific code to explain why any component whatsoever should be unable to run on whatever it likes. And the few cases where platform-specific code is missing (TSC access was, at one point, a common problem), it's either not difficult to add or not difficult to dummy up.
Finally, there needs to be a cleaner and clearer implementation of real-time under Linux, particularly because of virtualization. With multiple OS' on a single box, you split real-time into two groups - real-time from the OS' perspective (ie: it is guaranteed a close-to-fixed N/M fraction of any given slice of the OS' logical time to run in) and real-time from the box' perspective (ie: it is guaranteed a close-to-fixed N/M fraction of any given slice of the box' physical time to run in). Each type of real-time will have distinct requirements and there must be some way of clearly stating the maximum permitted variance for both any individual instance and for the run as a whole. These will mean API changes as well as infrastructure changes to the scheduler.
Ok, so we've got all of these large components welded into place and have a 3.1.3.x version that has stabilized and has eliminated bugs that would require major structural changes - and preferably more besides. Your 3.1.4.0.x version becomes a snapshot at which heavy-duty changes are unlikely. You then cycle up through the inevitable brown-paper-bag bugs to 3.1.4.1.0, whic
Seriously, 1.0 was considered "feature complete" at the time of release, and there are some major architectural changes which will be required in order to improve scalability across multi-core as well as SMP systems, not to mention some fairly major pieces of work that are still under development which will need to be merged fully at some point (DAPL being one of the bigger). With the growth in the cluster market, I would also expect some meta-structure to go in to support the basic concepts. Even PCI-e 2.1 support is going to have a serious impact, due to the changes introduced in it.
If I was in Linus' shoes, I'd be pushing for these big infrastructure components to be readied and maybe placed in the -mm tree at this point. Once they're ready for the big time - which might take a while - I'd migrate them into the main tree and wait three or four cycles for last-minute bugs to settle down, then flip to 3.0 to mark the first of a generation of kernels that are keeping pace with the curve. I'd reserve 4.0 for when Linux is not only stable for mainstream use but defines the curve for OS development. I think everyone on Slashdot is at least aware of the research into new hardware technologies, new OS technologies and so on, so I don't think anyone seriously believes that Linux won't undergo more fundamental changes in its life.
Obviously, I am not Linus and he gets to do what he wants, whether I - or anyone else - would agree with his beliefs or not. However, his reluctance to flip digits is not new - I remember when kernels had a letter at the end to mark the sub-sub-version and it had to go into 2 letters because Linus ran out of alphabet. I also remember the first time sub-sub-version numbers ran into the hundreds. On both occasions, there was gigantic frustration with the absurdity. I guess he's forgotten the problems caused, or something.
The screen is inherently an output-only device, and framebuffers allow you to direct output from an application to the screen in a mixed text-and-graphics mode. To me, that makes it as much a UI as anything else. It's not fancy, but neither was the mixed mode for the BBC Micro or the Apple IIe. If those were UIs, then so's a framebuffer.
Framebuffers. Nyah! :)
It depends. I would suggest using 1d4 for every 1.544 MB/s (equiv to a T1) that a line can carry to determine its XP value, as the faster a line is, the harder it will be to hit.
(It is also worth noting that the Lib Dems control a very large number of local authorities. Pissing them off can therefore have interesting consequences. It would be most unfortunate if a new sewer had to be installed in the road... right outside an MP's house... Terrible... Don't know how that could have happened...)
Both the opposition and the third party have other weapons that do not exist in America. Either can call for a motion of no confidence, in which the Prime Minister MUST appear to answer questions. As indeed they must for Parliamentary Question Time. Although it has not been used this way for years, it used to be standard practice to use no confidence motions to force the other party to turn up for important debates, as the Prime Minister must resign if the motion passes. It is vital to that party that it can guarantee as large a majority as possible. Question Time is also important, as it creates a much greater sense of accountability. It's not perfect, but it gets better answers than subpoenas seem to be in America.
The benefit of this is that we don't have to imagine any new processes or classes of stellar object. All we have to be able to imagine is that the winds within the galaxy are potentially highly variable. It just seems as though this would be an easier, simpler explanation. It just wouldn't be an explanation that would get media coverage or additional grant funding.
There are also other variants of these objects - magnetars, for example - that are, if not well-known, then at least recognized and classified.
To decide this could be something totally new is an interesting decision but nothing in the press release is telling me why they have made that specific decision over, say, merely seeing a regular pulsar at too great an angle to ever see the pulses.
Silver birch sap wine is actually very nice, so this might be worth trying out. Thanks for the link.
Cost-effective is the key to this, though. This is where multi-core systems matter. With a multi-core system, you have essentially one shared I/O bus through which all data is delivered. On the MIPS chips, this I/O bus (the Z bus) was also used for all CPU-to-CPU traffic, I don't know if this is the case on 80x86 systems. Essentially, though, you have a severe bottleneck.
Any N-way CPU must check every core for requests/posts - probably in a round-robin fashion - and then manage which core has the lock on the bus at any given time. The more cores you have, the more likely two cores will want the bus at the same time, the greater the net latency of the system. Eventually, adding more cores will actually slow the system down. In most SMP and multi-core systems, there are bottlenecks somewhere in the arrangement that will pretty much die above 16 cores.
So, to build a 64-way system that is even equal in performance to a 16-way system, you must either have an MxN-way system where each N-way CPU is wholly independent from the M-1 other CPUs, even though they are on the same silicon (essentially operating at the level of a cluster rather than a multi-core chip) OR you must ramp up the bus speed by a factor of 16 to handle the extra traffic and overheads.
From an architectural standpoint, a cluster is dirt-cheap compared to increasing bus speeds by that amount. Running lines from wafer to wafer is not cheap. It is very expensive, as you pointed out. BUT it only has to be cheaper than building a 48 gigahertz I/O bus in order to be cost-effective for the same level of performance per unit volume occupied by the system.
(Volume is important, as the cheapest solution of all per unit of performance is to build a giant heterogeneous cluster such that traffic never needs to go much beyond nearest neighbor, and have a butterfly network linking the nodes together. It will take up a lot more room than a single-stack or double-stack CPU - indeed, it will likely take up a room in many cases - but you will never build a CPU that can outperform such a cluster for the same price, simply because costs increase superlinearly or exponentially with the speed of an individual component, but are linearly divisible across multiple components.)
Oh, well that one's easy to solve. Lazy and incompetent scientists and archaeologists get to provide organic supports within the concrete structures. Everything else gets sorted out by Darwinian mechanics.
When it comes to old technologies, some things are superb and some things have proven a disaster. Floppies didn't start with the 5.25" - the 8" was older and is even less readable. Long before floppies, you had core memory. Good for 100+ years! But in less than half that time, I doubt there are many systems that could actually read the damn thing without wiping it. (Core was destructive on read, so you had to perform a write for every read into the correct address space.)
On ancient technology, more than one archaeological site has been utterly destroyed - partially or totally unmapped and unstudied - because some country or other wanted to build a dam. Water is important, sure, but you can collect water in any number of ways, and even if the dam is imperative, it'll take years to decades to build. Allowing scientists a few months to collect irreplaceable data isn't going to kill anyone or anything. Denying them does kill our chances of understanding the past. We only have one history, once it's gone, it's gone. It is, sadly, very easy to destroy and politicians have done much to destroy it.
I also prefer the idea of virtual cores over physical cores for the same reason. You can "steal" unused processing elements from a virtual core, therefore you can improve the total amount of processing elements in active use and therefore the efficiency and parallelism. The pipelines to each processing element would only need to be deep enough to produce an effective illusion of having that many physical cores.
What do you do when the task is already reduced to the simplest level? Well, you want to shorten the critical path by selecting different processing elements where a choice is available. You want to have the cache profile what is being used, so that retention is based on experience. (This allows you to exceed the theoretical best performance of a dumb caching system.) You want to break things down to a finer level of granularity (if you can) because that may provide opportunities for superior caching and superior parallelizing.
How do you tune and load-balance when the hardware is at 100%? Well, you want to know if it's the ideal 100%. Better profiling of cache activity may reduce off-chip I/O by avoiding dropping items you will shortly need. Since hotter chips are more likely to be subject to errors, and errors generate latency, tuning may involve better cooling. Since the internal bandwidth is greater than the off-chip bandwidth, and since you are limited by the critical path, your true performance requires you to tune cache I/O and CPU usage in parallel. This can mean that you get superior performance by detuning the processor elements so that the I/O can be more evenly distributed and therefore superior.
I don't think much extra scheduling hardware is needed, beyond some very simple profiling work and some basic multi-way analysis.
However, I don't think any of this is the best way to improve CPUs. The best way, IMHO, is to build a two-layer chip - one layer being RAM, the other being the CPU cores - where the RAM is running at 100% of the speed of the cores. Eliminate the outer level of cache and eliminate most of the I/O saturation issues. Sure, it'd be more expensive than a conventional design. At least, initially. All new designs are more expensive. And we're also talking about more expensive than a slower system, don't forget. By accelerating RAM to CPU speeds, eliminating a layer of pipelining and caching, and wiring each core to RAM pretty much directly, the ability for each core to do work is independent of the number of cores, provided writes are to different parts of RAM. When everything is funneled into a narrow pipeline, it's no different from funneling a hundred junctions onto a narrow Interstate. You will suffer horribly. A single CPU with multiple cores generally hasn't the I/O capacity to handle all cores performing I/O at once. If you want to avoid more complicated scheduling - needed to maximize total throughput - then you need to increase the I/O capacity and there is no easier way to do that than to have a dedicated I/O connection per core in addition to any core-to-core lines.
Long, fast, parallel - pick two. If fast and parallel are paramount, then you need very very short connections, which means you want two back-to-back wafers with lines running between them. The distances can't be any shorter than that, without having the cores or processing elements too far apart, with all the problems that causes.
Based on those examples, I would say that genuine progress by Intel is slow, and that any sudden shifts are really the result of having already produced the technology and holding it back.
Yes, but which type of birch? To quote Wikipedia, "Birch is the name of any tree of the genus Betula (Bé-tu-la), in the family Betulaceae, closely related to the beech/oak family, Fagaceae". The article there goes on to list 32 genetically distinct types of birch tree. I can't see how they'd produce identical chewing gum and I seriously doubt that every single variety would even be safe.
On the other end of the spectrum - literally - you have Dense Wavelength Division Multiplexing devices that can stack up as many parallel transmissions on a single fiber as the fiber has optical quality to carry. This is where you can get into the realms of terabits per second and even petabits per second. This doesn't come cheap. If you want high-end gear, you're looking at $150,000 total. Very high end, you can probably add a zero or two to that, but getting the actual prices becomes hard.
Typical gear for lighting up dark fiber is around ten grand. That is more than enough to get the hardware needed to build a good metronet or a fairly decent city-to-city link.
Ten thousand is a bit much for a student science project, but most cities waste more than that each year just to use up their budgets to avoid cuts the year after. If you put that wastage into infrastructure, gigabit links to private homes would be entirely within reach.
Now, if you were to ask me what I would like, I'd like a mesh city-to-city network that boasted petabit speeds - well within the highest speed recorded for thousand-mile links - and where within each city there was a metro-wide network that stepped the speeds downwards at the smaller scales. Each block would then be provided with a set of taps and it would be up to the owners of the buildings on that block on how to handle the distribution. A rural area would be a spur off the nearest metro-area network and would be treated as N many city blocks, depending on population. Again, the line in would be provided but locals take care of the last segment.
(This is not dissimilar to the current ISP notion of the "last mile", except I would rather that those using it have control over it. The "last mile" is the part ISPs care least about, because that's one connection and therefore the smallest unit of income. It's far far better if those who place greatest value in it have greatest say in it.)
Where does this leave ISPs, though? Well, cable is usually delivered by having stages of taps and so we know this model works. Meshes are used by some ISPs already - Telus in Canada is not a good example, but they do at least illustrate that I'm not talking mom-and-pop shops here. The charging mechanism for the Internet - by bandwidth - is best suited to hierarchies of provider, each working at different speeds, rather than conglomerates offering everything, as it distributes the costs out better.
What about freedom to choose ISP? Who gives a f? When you buy water from a different company or electricity from a different company, you don't get new plumbing or wiring. You don't get a different product. You merely get a bill with a different letterhead. It's like having all these brand names in stores, only to discover that the products all come from the same factory. You don't have this "choice", unless you can choose something different.
With the Internet, things are no different. 90% of the connection is common, no matter who you use as a provider. If you use DSL, virtually all of the phone line is common, no matter who you use as the provider. When you pick a provider, you are picking one - maybe two - routers, which you can pretty much guarantee are either Juniper or Cisco, and the IQ of the person maintaining them. Since both are relatively easy to maintain, this need not be very high in order to obtain perfectly reasonable service. Which, in some cases, is just as well.
If you have no real choice anyway, what possible difference can it make if all the ISPs use the same infrastructure and use the same billing structure as all the other vendors you buy from? At least there'll be fewer components in the system (so giving you greater reliability) and more paths to reach the destination (so again giving you greater reliability).
Of course, the Government could just create a Department of Por^H^H^HInformation Technology and run the whole thing centrally. If done correctly, it would eliminate the middle men and reduce the inevitable squabbling over where the taps will go. Privacy would be unaffected, as we know they've got sniffers in AT&T and probably other providers, and in fact inter-Departmental rivalry would probably protect it a whole lot more than the corporate sector has.
Graphical interfaces? Yes. CAS Online had a full sentence parser hooked up to a SQL database that could churn out full 3D rotating molecules, research papers, the works. When I compare it to the web of today, I despair. The best commercial sites run at a fraction of the speed, have a far more convoluted interface, and true 3D over the web has become more mythology than technology.
But was this available to the masses? Sure! Anyone could sign up for an IPSS account. It wasn't cheap, but it wasn't bank-breaking either. All you needed was a computer and a modem.
So what was the problem? There was no problem, by and large. The uptake of IPSS - particularly after MUD1 got mentioned in PCW and Practical Computing - was substantial. Far more people used it than used PRESTEL or other such online services.
FidoNet - well, FidoNet was treated as something dirty and inferior. Which, frankly, it was. You couldn't log onto computers anywhere in the world over FidoNet. You couldn't get genuine 2D or 3D vector or bitmapped graphics through FidoNet. As a bulletin board, it was considered vastly inferior to TBBS (The Bread Board System) which was a very popular system in Britain in the 80s. I can't think of a single site in Britain on any of the BBS lists published by mainstream sources that were FidoNet.
Oh, as for being elitist - yes, I guess I am. I most certainly do not believe in compromising quality for quantity. I also believe that you need not compromise quantity for quality, except maybe at the start. I believe in the inherent superiority of all solutions that give everything and compromise nothing. I believe in the inherent inferiority of those who deprive others of either quality or quantity (or both) for the sake of money they will never see, never need, never use and never value except insofar as it is a score in a game they play with other inferior-types.
No, not all people who make money fall into this category. The point is, money has no intrinsic meaning or worth. It only has value insofar as it enables you to do something. If you're making so much money that nothing further can be enabled, then yes I will look down on you - and have good reason to, too. If you let it rot in worth and enable nothing, simply to claim a better high score on a league table somewhere, I'd consider myself so far above that I'd need a telescope to look down that far. These are the attitudes of ISPs and backbone providers, and far too many content providers. As a result, I sneer at their pathetic greed and - to quote a Python - fart in their general direction.
(At this point, there would be a good case for blocking all e-mail traffic on the Internet backbone for a week, then on the assumption that anything still sending after the first day is a zombie, simply banning the entire offending network until it cleans up. Sure, it would cause chaos, but the economic and personal damage done by a week's shutdown would be minuscule compared to the expense paid on a continual basis because of spammers and malware.)
There are plenty of proxies for Linux (and Windows) that'll present their own browser IDs. This has the advantage that if you're running a home network, all machines on the home network will appear the same way. If the proxy is caching, it will also reduce the bandwidth requirements. That can be important, when downloading free po^H^Hsoftware.
...I'd quite like it if they used weather symbols to indicate the probability of adoption and timeframe, and the degree of concern over it. For example, sun mixed with cloud would indicate prospect of being adopted in near future. Lightning would indicate that it'd be adopted over the dead bodies of 50% or more of the list.
The seating must be in the Complex domain, and for the output to generate the necessary synchrotron tachyon, the banana must be entangled with the fish in the tailpipe, as postulated by Minsky space.