Intel's latest creations are basically x86-themed Transputers, which everyone (other than Intel) has been quite aware was inevitable. The only possible rival was processor-in-memory, but the research there has been dead for too long.
Interconnects are the challenge, but Infiniband is fast and the only reason Lightfleet never got their system working is because they hired managers. I could match Infiniband speeds inside of a month, using a wireless optical interconnect, with a budget similar to the one they started with.
Hard drives - you're doing it wrong. The drive should be battery-backed and have significant amounts of RAM on the controller. By significant, I mean enough to ensure that typical users will not be capable of distinguishing the hard drive from a RAM disk AND to ensure physical writes are delayed long enough that you maximize the number of writes that can be done as a sustained burst. (This reduces drive head movement, simultaneously making writes faster and drives longer-lasting.) Since this requires smart drives, you might as well have an OS on there. No sense wasting your main CPUs on filesystem work that can sensibly be offloaded.
For chips, for chrissakes get with the picture! Wafer-scale integration is the only way to go! There was also recently talk of some new gallium compound-on-silicon approach, with the gallium compound providing the transistors, silicon the connections. Interesting, but the US has outsourced almost all chip manufacture. If they want the new materials, they'll need to train a new generation of engineers and build new plants. If they're going to do that anyway, go wafer-scale. The initial costs will be high, when using the new materials, so you might as well go for broke and make the new stuff just too damn good to not get.
What's left? Ah yes, software. Easy. Pass a law stating that in order to get government funding, schools should teach Occam-pi and not Java. Big government? Too bad. Code quality out there is shite. The only way to fix that is to break bad code. Well, that or put the worst 10% of students likely to turn professional against the wall. However, that would produce a backlash. You could put bags of skittles in their pockets, I suppose.
There. That's the supercomputer industry fixed for another couple of decades. Do I get paid for this?
For a regular currency, which actually represents commodities. Bitcoin is a representation of currency, so it is two steps from the physical, not one. You therefore have to invert the sense.
In this case, a product selling for one bitcoin two years ago required that you spend $18. Last year, that same product was worth $150. Yesterday, it was worth $900. The bitcoins are just tokens, so the number of them doesn't matter. What matters is the amount of cash MtGox will take from you and the amount the recipients will get.
Currency is merely a token-based barter system. National currencies buy things, bitcoins buy national currencies. A bitcoin, by itself, has no intrinsic value and no barter value at the physical level. Nor will they ever have. National currencies only do because the sum of all currency is always equal to the value of something - the nation itself, these days. A cent equals one share in the nation of the US. A definite, physical thing. Doubling the amount of currency (creating more shares) halves the value of each share. By exchanging currency for something, you are saying that that many shares represents the same percentage of ownership of American products as the product itself. If you like, you are trading virtual ownership of the thing for physical ownership. I see no difference between that and the iron rings used in Europe around 500 BC. Except dollars are lighter and cents are stupider.
It is no different for bitcoins and national currency. You and another person barter (yes, it's barter!) on a price and then swap one for the other. You cannot barter bitcoins for products any more than you can cast generic strings to floats. Well, you can, but it has no meaning. You can only barter compatible types - currency for currency, share for share.
That doesn't make bitcoins less of a currency. If it wasn't a currency, you couldn't barter currency for it. Duh. It actually makes it a meta-currency, a more abstract currency. Which is a GOOD THING because if it was share-driven, like national currency, you have to have something that originated the shares. A BAD THING in a decentralized system. (Economics 1066 and All That.)
Now, going back to the inversion property. Each level out from the original item can be regarded as an image, with the bartering at that level acting as a lens, mirror or some other single-step image-generating process. More merchandise equals more physical things to own equals greater value. More national currency equals more shares equals less national value. The next step cannot produce even less value, because it isn't a share of a share. It is a standard unit. Amongst users, at any rate. Nations currently peg against the dollar, but that is changing. It is inevitable in the long term that they will peg against a cryptocurrency because those have (relatively) fixed quantity and shares in nations do not. Electronic gold, if you like.
This means two things. It means that inflation/deflation swap meanings, because these terms refer to barter value against things. It also means bitcoins can never replace a national currency. In both cases, it is the wrong level of abstraction.
Basically, almost nothing anyone (me included) ever learned about economics will apply to bitcoins. Directly, at any rate. Economics makes assumptions that cannot be guaranteed to hold in the abstract. The rules were never designed with abstraction in mind. Some will end up holding, because not everything is defined by the inheriting class of container, some things are defined by the parent object or further up. But nobody knows which. Hell, the Great Recession was due to the rules not even applying across the child classes.
Between radio SETI and optical SETI, new technology is inevitable, technology that can be patented or sold. Isolating data from a planet orbiting a star is going to require variable interferometry of a sort we don't yet have. New algorithms will be needed, as you can't sift through billions of channels for information content efficiently with what we have.
This means you can have a well-defined ROI even if nothing is ever found. And that means you can value SETI in terms of that ROI, which means you can float SETI on the market. Make it something with worth defined in terms others can understand.
Just as importantly, make it something the government regrets ignoring. They can talk all they like about the benefits of private enterprise, but they have legal restrictions on buying foreign technology or using the services of people without clearance. Signals analysis is signals analysis, meaning Russia and China will likely be involved in any open research, meaning the US will have all kinds of legal hoops to jump through. That or buy the shares in some way, thus funding the work and keeping sigint stuff out of the hands of imagined enemies.
In short, use the obsession with private funds to back Five Eyes against the wall. Give these nations no choice but to give SETI the money needed.
The NSA designed almost all existant crypto to be breakable by them, and from the looks of what The Guardian has been reporting, that includes SSL/TLS. The reports also make plain that they can waltz into any Windows or Mac without effort.
That means all online (or remotely accessible) wallets, online mining pools, bitcoin exchanges and bitcoin-accepting vendors are vulnerable, possibly already compromised. All bitcoin transactions via the Freedom Servers, regardless of destination, were certainly recorded and all bitcoins involved are potentially hijackable at any time.
Because the NSA weakened all crypto standards (ps: Do NOT use SHA 3 in the weaker forms, I am extremely suspicious of remarks made on the official SHA 3 mailing list regarding strength, though the stronger forms are probably ok), it is entirely within the realms of possibility that the NSA already has a complete list of all possible bitcoins. The currency depends on the maths being hard, but if it isn't, then you've nothing. They may also be capable of injecting false transactions - never trust enthusiastic supporters in US security agencies, they aren't in the business for your health.
First, not really. Bitcoin is only usable because those IOUs exist. (Well, they're not really IOUs, since the sum value of hard currency will always equal the sum value of what they're pegged against. A floating currency is pegged against the nation. Print all the hard currency you like, the value per unit will drop until equilibrium is reached. They are shares, just like any other, and are priced by the market just like any other.)
Because the sum of the hard currency ALWAYS equals the sum of the goods and services available, a virtual currency for goods and services cannot have value if the hard currency has no value, since they value precisely the same thing.
Can bitcoin actually buy goods and services, though? One pizza place is a start, but not a very exciting one. Mondo started with the entire town of Swansea and still didn't get enough momentum going. The only way to currently use bitcoins for anything* is to convert them at places like MtGox for hard currency.
*Anything not pizza. Or drugs. I suppose I should include that, since there are bound to be people wanting to recreate the Excel flight simulator effect.
Have to say you make excellent points. It's why I avoided even looking at bitcoin for the longest time. (Early on, the value was less than the cost of the electricity and as the computations were only going to get harder, the likelihood of benefits was nil. It didn't help that something for nothing often ends badly for the people who think they're paying nothing.)
Really, for a good virtual currency, you need it pre-generated and beyond the ability of computers in the next 30-40 years to potentially break. 150-200 years would be ideal. That isn't bitcoin. Don't get me wrong, bitcoin looks less vulnerable to counterfeiting than regular currencies, but I remain unconvinced that it will prove strong over the lifetime of currencies. When currency lifetimes are measured in centuries, knowing something was strong last week isn't really good enough.
(I can't say the US decision thrills me, knowing that the same people applauding bitcoin have interfered with crypto development.)
What we have right now is hyperinflation due to rampant speculation. A few will get rich quick, a lot will get poor even quicker when the bubble bursts. We've seen, what, 800%, 900% inflation this year? Competing with Zimbabwe? This isn't remotely sustainable, especially as everyone and their pet dog can run a bitcoin miner and cash out via one of the ATMs or an exchange service.
We've also now seen cases of virtual bank robberies, with owners of online wallet services cutting and running. Yes, that happens with physical banks too, but all that tells me is that a lot of old problems remain, a lot of new problems are added, and still no sign of actual benefits.
I want a virtual currency that works. Mondo experimented with electronic cash in the late 80s, early 90s, where you had smart cards you could actually use in real stores to make payments without going via any bank. It was an interesting system, it used a real currency rather than a virtual one but that's immaterial as it could have used anything. The fact is, they had a working system for utilizing electronic money without involving central systems. It should be very easy to do better today and have more places adopt it.
Combine that with a currency that isn't scattered at random on some mathematical version of a sidewalk (pavement in the UK), and you'll have something that really does impress for all the right reasons.
Perfectly true. You seen the Open Source EEG at Radio Shack or Wal-Mart? Me neither. These sorts of devices don't sell in bulk and even the really good science tech out there rarely sells beyond the bare minimum needed to pay for development.
But only a start. Researchers using - it was either 48 or 64 leads - were able to identify specific muscles that were showing abnormalities long before those abnormalities turned into organ failure. Isolating problems to that degree just by collecting more of the same data would seem a great way to help prevent problems serious enough to show up on a conventional system ever developing in the first place.
In other words, why not turn thus from being open source medicine into an open source debugger? Why let things get to the point where medicine, rather than our own creativity is needed?
Modern medicine works on the basis that dead people rarely sue. The same goes for other mission-critical systems like fly-by-wire avionics. To be fair (me? fair? well, it was bound to happen eventually), a lot of companies put in a lot of effort to do a good job. The problem is, if you're on life-support or flying at 20,000 feet, there is every probability that a software crash will be followed by a crash of another sort. There have been very close calls of this nature in the past.
But what would happen in the event of a fatal incident? In virtually all industries that use mission-critical systems, there are disclaimers and waivers that prohibit lawsuits.
Even in non-critical systems, EULAs invariably state the manufacturer/developer is not at fault, no matter what, even if they admit they are, and to use the system you have to agree to that. You aren't given a choice.
Open Source licenses often say the same, but Open Source allows you to validate the system to your satisfaction. You are prohibited from any code analysis and certain forms of runtime analysis with closed systems. Thus, although neither provide any form of warranty or fitness for use guarantees, you are capable of at least certifying open source as fit for use. No commercial product using computers will provide anything remotely close.
The problem is with the definition of major. There are almost never minor improvements to the kernel, using conventional ideas of major and minor. Ergo, these terms need updating or removing. They serve no useful function in the context of the Linux kernel.
I've never gone above AudioEngine 2, which is respectable lower-middle range, but know audiophiles who wouldn't touch such cheap junk.
A person doesn't even have to be an audiophile, per-se. There was a recent Guardian interview with a "bushcrafter" (he hates the term "survivalist") who was able to demonstrate the ability to distinguish between species of tree by the difference in the sound through the leaves. On one hand, one might argue that such a person probably isn't likely to want to build a home theatre with sound to make an IMAX manager cry. On the other hand, what you really SHOULD be arguing is that if it is possible to train hearing to that degree in one person, it must occur in other people and therefore audio reproduction that is incapable of reproducing nuances at the required level and subtlety aren't capable of satisfying that fraction of those other people who DO want to build a home theatre with sound to make an IMAX manager cry.
Does it need to look good? Most home theatres are dim or dark, so provided it is in some sort of minimalistic cabinet, nobody is going to see it.
Totally immune to EMP. Besides, we need people to magnify the Casimir effect if we're to ever get wormhole technology. And, trust me on this, you do NOT want an evil general on the other side to go around suppressing it when you're half-way through.
It depends. Sound quality doesn't scale, generally, which is why standard speaker systems have vast arrays of speakers that operate over very narrow ranges. The sound quality using cones and magnets has gone as far as it can, short of moving to superconducting electromagnets.
There were some speakers demo'd on Tomorrow's World, way back when, which consisted of an electrode in a spherical wire mesh. The spark, pulsed at the right frequency, could generate sound. It was extremely high quality, far far higher than the Tesla Coil speakers you see on YouTube. But nothing ever came of the idea. Still not entirely sure why, but I suspect large amounts of ozone and the power you'd need to cross the gap they were using would make such a device uneconomic.
The nanotube idea is interesting, but I have a real concern that technology these days isn't about quality but quantity. Notice how the summary emphasizes the production of the system, but also observe how DVD lifespans are pathetic, hard drives have much shorter MTBF than earlier generations, MP3s largely replaced lossless codecs, digital cameras have a fraction of the effective pixel count of film, etc. Nobody wants high-end. They want crap that's tolerable and affordable. (Which also explains why Windows is a "success" and Linux has never made it to the desktop -- yet is the only serious OS in the few luxury/demanding markets left.)
It could be that nanotubes will prove to be capable of high-end sound, REAL hi-fi sound, but let's face facts. Even if it was, even given that the technology exists for 11.1 sound with an upper operating limit of 384 KHz at 24 bits, when was the last time you saw a CD with music recorded at that level? People want more tracks per piece of physical medium and would probably settle for 16 KHz at 16 bits resolution if it gave them a few more bonus tracks. There are audiophiles out there. I know. I'm one of them. Although, sometimes I think I'm the only one left. That depresses me, but you have to wonder. Purported audiophiles who can't tell what gives good sound and what doesn't clearly aren't audiophiles at all, they're blingophiles.
However, I shouldn't have much trouble getting a universal VM out a few days after that. After all, an OS itself is merely a virtual machine (a fact you've apparently forgotten) and writing a plugin framework that would allow bare metal drivers on one side and a collection of plugins to provide kernel level functionality on the other should not be hard. I don't need to have the plugins, beyond the minimum to offer a proof that I can run any set of system calls I care to write the plugins for on any set of hardware components I care to write the drivers for.
In fact, as several "bare metal" OS' already exist, as do several microkernels that allow OS' to be layered on top (ADEOS and L4 being two commonly-used ones), I probably don't have to do that. We already know Linux will run on any architecture for which an architecture module exists, so we know platform-independence is doable at the bare metal layer. Between the various experimental OS' out there, it should be possible to show that drivers doubling as abstraction layers (which are pretty common) can provide enough information for running the hardware to be efficient. (Think about how many abstraction layers Linux uses to go from a file open command to an actual hard drive operation. Yet that's very efficient.)
The main problem with writing a middle layer that supports multiple OS' is that different OS' have different internal data structures. Otherwise, from this basic starting point, anybody could write a generic OS in a weekend. What you can do, however, is have a layer that provides a whole bunch of different data structures that synchronize on write. You only need to refresh what's in use, so provided the userspace is kept simple, the kernel performance won't be killed, merely maimed. Since you don't actually have to care what driver does what, so long as what you want done is provided, we can start with Linux and simply write data structure converters for it.
How would this let you run OpenBSD apps? Or Windows apps? Or Solaris apps?
Well, what's in OpenBSD that isn't natively in Linux? pf and the filesystem. Oh, and the security, but if the NSA can remotely break into "any" box (as per the Guardian claim) then OpenBSD would need to have some exploitable flaw in the security, so for the people that matter, the security isn't necessarily that different.
Let's start with pf. There are two obvious approaches. First, you could take all the files from the OpenBSD source, create reflected structures that work with Linux' netfilter or the semi-mythical successor to it that will bear the unwelcome distinction of being released after Duke Nukem Forever, create the necessary header files and then essentially build pf as a Linux kernel module that operates inside netfilter. Not particularly efficient, as you're then partially running pf "natively" and partially running it as an emulated module. It would work, with enough time and effort, because ultimately logic is logic is logic.
By far the more practical method is to convert pf into a Z specification. Z is a bastard to work with, which is why most coders don't, but it's actually a very good way to clean-room implement something and know that you got the implementation 100% correct. (It's mostly a bastard because people are so inept at writing efficient code from specifications. However, if the specification is written from the code, it's already in a form that's efficient to code, by definition.)
Humans are staggeringly lazy. Nobody does anything unless they absolutely need to. This is why wars result in a lot of research and development being done. It's not because necessity is the mother of invention, it's because necessity is an axe-wielding psychopath that will slaughter anyone that doesn't do anything with all the projects, plans and papers that have been produced since the last war.
We need to explore the outer planets, less for the data that might be there (you can obtain the same volume of world-view-shattering data from many sources), but purely because it gives the engineers no choice but to actually get off their lazy collective arses and do something productive. (NB: I say engineers only because the managers are lost causes.)
Solar panels, no matter how good, won't help. All the sunlight falling on the entire of Jupiter would not power the computers, never mind ion drives, of an advanced probe, and there is simply no way of building solar panels larger than that. Lower power electronics are easy, we could do those tomorrow. Voyager 1 is running multiple instruments AND a long-range transmitter on a trace of power so low that most home multimeters wouldn't register it, and electronics are tens of thousands of times more efficient today than back then. (Further, if the probe is using an ion drive, you can store the data rather than sending it, which means you're not confined to bandwidth limitations or the horrible inefficiency of wireless.)
Reactors won't get lighter. Fission has gone as far as it can. Until someone develops working fusion, there will be no significant reactor development. In fact, most probes don't use reactors at all, they use nuclear batteries. Different technology.
Radio sensitivity won't help. Shannon showed that the retrievable information (even in theory) is not dependent on the sensitivity of the receiver or the power of the transmitter.
Mining asteroids is a waste of time. The cost will always exceed the benefit, even if you parked an asteroid made of solid gold in Earth orbit. Even if it could be made profitable, it merely encourages a waste of resources, and it is because humans waste resources so much that R&D never gets done until it's past too late.
Sending up better telescopes is seriously stupid. Crystals form better in microgravity and you won't get the mirror deformations that hindered Hubble so much, if you just build (from raw material) the entire telescope in space. In fact, park a disposable construction facility in orbit around the moon and you'd be able to build a defect-free optical telescope in space larger than the largest radio telescope on Earth.
Balloons to Venus would tell you nothing - we've already got a fairly decent surface map and the atmosphere would destroy any material you sent. No, if you send a probe to Venus, the only rational place to send it (and the only place we'd get new data) is below the surface itself. That means taking a small asteroid, putting your probe in the middle, then slamming the lot into Venus at a speed that'll vaporize most of the asteroid and put the rest plus probe deep enough underground to actually do real science on the planet prior to the utter destruction of anything left. This is way, way beyond what we can currently do, and even if it wasn't, we've far more to learn from asteroids than from Venus. Venus is a boring planet.
Mercury is also a boring planet. It's basically a lump of iron ore, with a few traces of other metals thrown in. Pretty much what you'd expect, given that the rotation of the accretion disc would have separated out the various elements very efficiently (which is why you see the types of planets where you do) and also given that Mercury shows strong evidence of being a planetary core with the outer parts of the planet blasted off at one time or another. It can tell you about planetary cores, if studied as a whole, but if you're limited to a few mm below the surface of two tiny, non-representative regions, then it can tell you nothing at all.
We already know from Doctor Who (Second Doctor, second story featuring the Ice Warriors) that humanity doesn't get beyond the moon until after transmat and weather control have been developed and we have a fully operational moonbase. Although the transmat part looks like it may be doable (despite incorrect calculations by cynics on how much data would be required), we're probably not going to see a moonbase and weather control is likely an impossibility.
Since these are prerequisites, I conclude that further travel than that will not happen. Since nobody will be going further, there will be no need to explore further. Whether, as Douglas Noel Adams' suggested, it turns out that leaving the oceans was a really bad idea is hard to say, but the lower 95% of the population seems determined to convince me that it was.
I program natively in more languages than you've had hot fixes. I've probably run more Linux kernel projects than you. And judging from your UID, I've roughly a thousand times the experience of software development.
By 99.5% the same, I do not mean implementation (which is immaterial and gets in the way of real work) but design. If you regard no function as a null function, then all OS' have a memory management API. It doesn't matter if it's the DOS idea of memory management (if it collides, it collides - survival of the fittest), the Linux idea (where there's compartmentalization, memory mapping and System V shares) or some other scheme. It's just an API for a black box.
And that's the whole point. Yes, there are modular OS' (Linux), monolithic OS' (OpenBSD), microkernels (L4) and even nanokernels, but that's architectural bullshit for the most part. For any given function in any given OS, there will be another OS in which you will need zero or more functions to perform the same task. But it will be performable.
The "ideal" is to write a pseudo OS - done these loads of times, they're fun - that performs all of the core operations you need in all OS'. (Games, for example, don't generally need to access the print spooler or OS-level password table much.) This pseudo OS can be written as a library and included by a compiler or cross compiler. (This is how Occam, Java and Smalltalk work, I'm not certain but am fairly sure it's how the Ada runtime works as well. Wine partially operates this way, as did the long-lamented IBCS2 module, but you're too young to remember that.)
The pseudo OS would have the same split as GCC - frontend that the user experiences and a backend that the machine experiences. In this case, the backend would be the ties from the pseudo OS to the actual OS you're running on. Which, again, is really how GCC works. I repeat myself. I need to. There are so many dumb users these days.
Anyways, that is how you make it possible to write one program for one environment and have it run everywhere. It is very very simple, it has been done many times, I would write another but I'm busy this weekend. Besides, you've not learned the ones that already exist, so why the hell should I write you another to prove the point?
Ideally, since a language IS just a virtual environment (it's not a real one, it's converted into a real environment) then your pseudo OS could be a programming language. Since libraries can be added to libraries, you can then build up the environment as far as you like, knowing that cross compiling to any supported OS will still work 100% of the time.
Thus, if you have a truly standard C compiler with true portability libraries for what you need but don't find in C, you achieve the precise result I describe. But, no, you'd rather whinge about how it can't be done, and how those who actually do this stuff can't really be programmers. Sorry, I learned programming before you learned how to subdivide your cells. The reason I consider coders these days to be complete wazzoks is that they don't understand any of the theory or how the theory applies to the practice.
NEVER trust the odd numbers. The even number patch releases are where they fix the problems with the odd number patch releases.
Basically, Microsoft is dealing with multiple Operating Systems for which no complete design document exists. For any of them. Microsoft is highly departmentalized and, in consequence, it is impossible for Microsoft to compile a single design for the entire system. They simply don't have the structure.
This is not necessarily a bad thing - things tend to be worse when unrelated subsystems start making assumptions about internal design that they shouldn't. It simply means the Windows environment is now too big for a corporation to manage. Microsoft has exceeded its maximum stable size, and has done for some time. (Based on quality of products, I'd say somewhere around the DOS 4.0 level, but that would be mean. Accurate but mean.)
The only reason I use MS products at all is that application developers go out of their way to be burdensome to non-MS users. Wine has a terrible time with many Windows applications and that's about the only way to run them at all. I would truly love developers to push platform-specifics into a library. It can be done. They can then either write libraries for other OS' or provide the API to that library so that others can write a porting library. It's not like it would hurt sales and it won't affect the game because it's purely a support module.
But, no, game companies and solo writers prefer their 1970s approach to coding - damn the portability, even if all OS' are 99.5% the same, and damn the sales, we want absolute totalitarian power! Bwahahahahahahahaha! Even if it'll eventually kill the product and the company. Who cares, when you're rich, powerful and utterly FUBAR!
Picture this. The Federal Government buys up dark fibre, or lays new fibre, such that there is a "Tier Zero" multi-path network between significant population centres regardless of State boundaries. Tier 1 ISPs can hook into this but the Government's networking is transparent so ISPs can't charge for traffic distance. Tier 1 ISPs aren't obliged to do so, though, and in either case this would not alter any peering agreement between Tier 1 providers. All it would do is provide extra stability, extra bandwidth and extra reach (Tier 1 ISPs could, via such a Tier Zero network, form peer-to-peer agreements even when a hostile Tier 1 geographically isolated the two).
Extra stability would cut Tier 1 costs (fast maintenance costs money, this would buy time for the Tier 1 to make quality repairs rather than cheap, natty repairs) but this would require the Government to charge for "diverted traffic" in a way that would make it cost-prohibitive to simply use the Government network and ignore their own but cost-effective as a way of handling the bursts the Tier 1s can't cope with without expensive upgrades. That's not getting support, that's becoming a parasite.
State Governments would then be allocated money specifically to connect schools, colleges, universities and accredited research centers (or to boost speeds where connections exist, or to offset costs if the speed is perfectly fine), and to build metropolitan mesh networks (at the wired and wireless levels) with support for Mobile IP (since users can be expected to move from node to node). This need not affect ISPs, as most of their customers are in the suburbs/sprawls anyway and the cost of laying down or replacing high-end hardware under city roads is going to be high enough that the profits there will be eaten into very quickly. What it does do is free up ISPs to reach customers further out where access has traditionally been poor. Not that they will, but they could. Customer-level ISPs wanting to remain in cities because they can add value would obviously be able to.
Virtually everything would remain private, except for those areas where individual companies don't have the means and/or motive to do the job right.
The level of security doesn't change, since the ISPs are all pwned by the NSA, you wouldn't get coast-to-coast disconnects due to a single fibre being cut by accident, and a city-wide mesh would speed up access to local information. Government would do what it does best and industry would do what it does best. So, naturally, everyone would complain.
I agree completely with your post. In essence, it boils down to Critical Path Analysis. The fastest a given page or data set can be delivered is equal to the speed of the critical path through the system. When you have heapsloads of parallelism, the critical path can span multiple threads and in some cases be impossible to determine.
My approach to layering is to simplify the CPA, make responses more deterministic and less vulnerable to accidental deadlocks when related pages are simultaneously accessed. That, alone, speeds things up.
Yes, PostgreSQL in charge is good, the lowest level is operating as a powerful pre-fetch that can also act as a sanity check to ensure reads don't write.
If a network fails before the system, then your system cannot fail in a distributed denial of service attack. Since any decent data centre multipaths, the failure of a network is of no significance.
Hey, wait! I am a 4 digit UID who has published code since the late 1970s! What the hell do I need to explain to some 6 digit street urchin? Face facts, you are nothing more than semi-evolved slime with the IQ of a desiccated dung beetle. You want to harass an old-timer? You think your pitiful excuse of a right-wing troll is worthy of consideration? Pffft!
As for your username, Wumpus is probably as intellectual as you can handle. Even a desiccated dung beetle has enough joints to handle the state space.
We can continue this on alt.flame, assuming you don't confuse that with a URL.
I mentioned NoSQL databases (so no marks for observation). The reason for the two layers of RDBMA is that you get a lot of potential blocks by loading everything onto one layer. Worse, you get heavy resource drainage when any serious crunching is done. One system I worked with took 5-6 minutes to complete a particular SQL query and often timed out. I refactored it down to 25 seconds, but that was far longer than I wanted. The tables were huge, swamping the database's caching capacity. The stored procedures were vast, even after refactoring. Intermediate tables were generated by other stored procedures. Moving those intermediate tables and related procedures to a different engine meant they could be fresher without killing the system, and since these tables were now views and not raw tables on the second tier, the security was better. Access times dropped to around 7 seconds.
So the three tier layout using some permutation of NoSQL/memcache, PostgreSQL and MySQL/MariaDB, for extremely heavy loads, is superior to trying to get one engine to digest everything.
For very light systems, obviously multi-tier systems are not going to be efficient. Each layer adds latency, and each layer that has excess capability adds latency. You want the lightest system that'll do what you want.
I started in the late 1980s on gigabyte databases, and they've only grown in size and complexity since then. Back then, I was asked to make the system handle real-time data streams from large gamma ray detector arrays. Which I did. I also managed to show that their network would suffer a meltdown before my software. My approach has been refined, over the years, to include understanding of different topologies (and how to thrash them into submission by writing custom high-performance network protocols), but my personal objective remains the same: there is no way in hell I will let my software suffer a meltdown before your hardware. My software WILL take the punishment you throw at it, give you the results AND complete The Times crossword before you've had time to register that you sent the query at all.
Because I know I can do this, I have little or no regard for programmers who cannot or will not. Anything I can do, they can do.
I've probably shipped more code than you'll run in a lifetime. What's more, it's damn fast code, highly robust and damn-near DDoS-proof. You? Pffft! Your comprehension of systems is only marginally superior to your comprehension of quantum gravity.
Slashdot Mirror
Intel's latest creations are basically x86-themed Transputers, which everyone (other than Intel) has been quite aware was inevitable. The only possible rival was processor-in-memory, but the research there has been dead for too long.
Interconnects are the challenge, but Infiniband is fast and the only reason Lightfleet never got their system working is because they hired managers. I could match Infiniband speeds inside of a month, using a wireless optical interconnect, with a budget similar to the one they started with.
Hard drives - you're doing it wrong. The drive should be battery-backed and have significant amounts of RAM on the controller. By significant, I mean enough to ensure that typical users will not be capable of distinguishing the hard drive from a RAM disk AND to ensure physical writes are delayed long enough that you maximize the number of writes that can be done as a sustained burst. (This reduces drive head movement, simultaneously making writes faster and drives longer-lasting.) Since this requires smart drives, you might as well have an OS on there. No sense wasting your main CPUs on filesystem work that can sensibly be offloaded.
For chips, for chrissakes get with the picture! Wafer-scale integration is the only way to go! There was also recently talk of some new gallium compound-on-silicon approach, with the gallium compound providing the transistors, silicon the connections. Interesting, but the US has outsourced almost all chip manufacture. If they want the new materials, they'll need to train a new generation of engineers and build new plants. If they're going to do that anyway, go wafer-scale. The initial costs will be high, when using the new materials, so you might as well go for broke and make the new stuff just too damn good to not get.
What's left? Ah yes, software. Easy. Pass a law stating that in order to get government funding, schools should teach Occam-pi and not Java. Big government? Too bad. Code quality out there is shite. The only way to fix that is to break bad code. Well, that or put the worst 10% of students likely to turn professional against the wall. However, that would produce a backlash. You could put bags of skittles in their pockets, I suppose.
There. That's the supercomputer industry fixed for another couple of decades. Do I get paid for this?
For a regular currency, which actually represents commodities. Bitcoin is a representation of currency, so it is two steps from the physical, not one. You therefore have to invert the sense.
In this case, a product selling for one bitcoin two years ago required that you spend $18. Last year, that same product was worth $150. Yesterday, it was worth $900. The bitcoins are just tokens, so the number of them doesn't matter. What matters is the amount of cash MtGox will take from you and the amount the recipients will get.
Currency is merely a token-based barter system. National currencies buy things, bitcoins buy national currencies. A bitcoin, by itself, has no intrinsic value and no barter value at the physical level. Nor will they ever have. National currencies only do because the sum of all currency is always equal to the value of something - the nation itself, these days. A cent equals one share in the nation of the US. A definite, physical thing. Doubling the amount of currency (creating more shares) halves the value of each share. By exchanging currency for something, you are saying that that many shares represents the same percentage of ownership of American products as the product itself. If you like, you are trading virtual ownership of the thing for physical ownership. I see no difference between that and the iron rings used in Europe around 500 BC. Except dollars are lighter and cents are stupider.
It is no different for bitcoins and national currency. You and another person barter (yes, it's barter!) on a price and then swap one for the other. You cannot barter bitcoins for products any more than you can cast generic strings to floats. Well, you can, but it has no meaning. You can only barter compatible types - currency for currency, share for share.
That doesn't make bitcoins less of a currency. If it wasn't a currency, you couldn't barter currency for it. Duh. It actually makes it a meta-currency, a more abstract currency. Which is a GOOD THING because if it was share-driven, like national currency, you have to have something that originated the shares. A BAD THING in a decentralized system. (Economics 1066 and All That.)
Now, going back to the inversion property. Each level out from the original item can be regarded as an image, with the bartering at that level acting as a lens, mirror or some other single-step image-generating process. More merchandise equals more physical things to own equals greater value. More national currency equals more shares equals less national value. The next step cannot produce even less value, because it isn't a share of a share. It is a standard unit. Amongst users, at any rate. Nations currently peg against the dollar, but that is changing. It is inevitable in the long term that they will peg against a cryptocurrency because those have (relatively) fixed quantity and shares in nations do not. Electronic gold, if you like.
This means two things. It means that inflation/deflation swap meanings, because these terms refer to barter value against things. It also means bitcoins can never replace a national currency. In both cases, it is the wrong level of abstraction.
Basically, almost nothing anyone (me included) ever learned about economics will apply to bitcoins. Directly, at any rate. Economics makes assumptions that cannot be guaranteed to hold in the abstract. The rules were never designed with abstraction in mind. Some will end up holding, because not everything is defined by the inheriting class of container, some things are defined by the parent object or further up. But nobody knows which. Hell, the Great Recession was due to the rules not even applying across the child classes.
Between radio SETI and optical SETI, new technology is inevitable, technology that can be patented or sold. Isolating data from a planet orbiting a star is going to require variable interferometry of a sort we don't yet have. New algorithms will be needed, as you can't sift through billions of channels for information content efficiently with what we have.
This means you can have a well-defined ROI even if nothing is ever found. And that means you can value SETI in terms of that ROI, which means you can float SETI on the market. Make it something with worth defined in terms others can understand.
Just as importantly, make it something the government regrets ignoring. They can talk all they like about the benefits of private enterprise, but they have legal restrictions on buying foreign technology or using the services of people without clearance. Signals analysis is signals analysis, meaning Russia and China will likely be involved in any open research, meaning the US will have all kinds of legal hoops to jump through. That or buy the shares in some way, thus funding the work and keeping sigint stuff out of the hands of imagined enemies.
In short, use the obsession with private funds to back Five Eyes against the wall. Give these nations no choice but to give SETI the money needed.
The NSA designed almost all existant crypto to be breakable by them, and from the looks of what The Guardian has been reporting, that includes SSL/TLS. The reports also make plain that they can waltz into any Windows or Mac without effort.
That means all online (or remotely accessible) wallets, online mining pools, bitcoin exchanges and bitcoin-accepting vendors are vulnerable, possibly already compromised. All bitcoin transactions via the Freedom Servers, regardless of destination, were certainly recorded and all bitcoins involved are potentially hijackable at any time.
Because the NSA weakened all crypto standards (ps: Do NOT use SHA 3 in the weaker forms, I am extremely suspicious of remarks made on the official SHA 3 mailing list regarding strength, though the stronger forms are probably ok), it is entirely within the realms of possibility that the NSA already has a complete list of all possible bitcoins. The currency depends on the maths being hard, but if it isn't, then you've nothing. They may also be capable of injecting false transactions - never trust enthusiastic supporters in US security agencies, they aren't in the business for your health.
First, not really. Bitcoin is only usable because those IOUs exist. (Well, they're not really IOUs, since the sum value of hard currency will always equal the sum value of what they're pegged against. A floating currency is pegged against the nation. Print all the hard currency you like, the value per unit will drop until equilibrium is reached. They are shares, just like any other, and are priced by the market just like any other.)
Because the sum of the hard currency ALWAYS equals the sum of the goods and services available, a virtual currency for goods and services cannot have value if the hard currency has no value, since they value precisely the same thing.
Can bitcoin actually buy goods and services, though? One pizza place is a start, but not a very exciting one. Mondo started with the entire town of Swansea and still didn't get enough momentum going. The only way to currently use bitcoins for anything* is to convert them at places like MtGox for hard currency.
*Anything not pizza. Or drugs. I suppose I should include that, since there are bound to be people wanting to recreate the Excel flight simulator effect.
Have to say you make excellent points. It's why I avoided even looking at bitcoin for the longest time. (Early on, the value was less than the cost of the electricity and as the computations were only going to get harder, the likelihood of benefits was nil. It didn't help that something for nothing often ends badly for the people who think they're paying nothing.)
Really, for a good virtual currency, you need it pre-generated and beyond the ability of computers in the next 30-40 years to potentially break. 150-200 years would be ideal. That isn't bitcoin. Don't get me wrong, bitcoin looks less vulnerable to counterfeiting than regular currencies, but I remain unconvinced that it will prove strong over the lifetime of currencies. When currency lifetimes are measured in centuries, knowing something was strong last week isn't really good enough.
(I can't say the US decision thrills me, knowing that the same people applauding bitcoin have interfered with crypto development.)
What we have right now is hyperinflation due to rampant speculation. A few will get rich quick, a lot will get poor even quicker when the bubble bursts. We've seen, what, 800%, 900% inflation this year? Competing with Zimbabwe? This isn't remotely sustainable, especially as everyone and their pet dog can run a bitcoin miner and cash out via one of the ATMs or an exchange service.
We've also now seen cases of virtual bank robberies, with owners of online wallet services cutting and running. Yes, that happens with physical banks too, but all that tells me is that a lot of old problems remain, a lot of new problems are added, and still no sign of actual benefits.
I want a virtual currency that works. Mondo experimented with electronic cash in the late 80s, early 90s, where you had smart cards you could actually use in real stores to make payments without going via any bank. It was an interesting system, it used a real currency rather than a virtual one but that's immaterial as it could have used anything. The fact is, they had a working system for utilizing electronic money without involving central systems. It should be very easy to do better today and have more places adopt it.
Combine that with a currency that isn't scattered at random on some mathematical version of a sidewalk (pavement in the UK), and you'll have something that really does impress for all the right reasons.
Perfectly true. You seen the Open Source EEG at Radio Shack or Wal-Mart? Me neither. These sorts of devices don't sell in bulk and even the really good science tech out there rarely sells beyond the bare minimum needed to pay for development.
This device is good, but not that calibre.
But only a start. Researchers using - it was either 48 or 64 leads - were able to identify specific muscles that were showing abnormalities long before those abnormalities turned into organ failure. Isolating problems to that degree just by collecting more of the same data would seem a great way to help prevent problems serious enough to show up on a conventional system ever developing in the first place.
In other words, why not turn thus from being open source medicine into an open source debugger? Why let things get to the point where medicine, rather than our own creativity is needed?
Modern medicine works on the basis that dead people rarely sue. The same goes for other mission-critical systems like fly-by-wire avionics. To be fair (me? fair? well, it was bound to happen eventually), a lot of companies put in a lot of effort to do a good job. The problem is, if you're on life-support or flying at 20,000 feet, there is every probability that a software crash will be followed by a crash of another sort. There have been very close calls of this nature in the past.
But what would happen in the event of a fatal incident? In virtually all industries that use mission-critical systems, there are disclaimers and waivers that prohibit lawsuits.
Even in non-critical systems, EULAs invariably state the manufacturer/developer is not at fault, no matter what, even if they admit they are, and to use the system you have to agree to that. You aren't given a choice.
Open Source licenses often say the same, but Open Source allows you to validate the system to your satisfaction. You are prohibited from any code analysis and certain forms of runtime analysis with closed systems. Thus, although neither provide any form of warranty or fitness for use guarantees, you are capable of at least certifying open source as fit for use. No commercial product using computers will provide anything remotely close.
The problem is with the definition of major. There are almost never minor improvements to the kernel, using conventional ideas of major and minor. Ergo, these terms need updating or removing. They serve no useful function in the context of the Linux kernel.
I've never gone above AudioEngine 2, which is respectable lower-middle range, but know audiophiles who wouldn't touch such cheap junk.
A person doesn't even have to be an audiophile, per-se. There was a recent Guardian interview with a "bushcrafter" (he hates the term "survivalist") who was able to demonstrate the ability to distinguish between species of tree by the difference in the sound through the leaves. On one hand, one might argue that such a person probably isn't likely to want to build a home theatre with sound to make an IMAX manager cry. On the other hand, what you really SHOULD be arguing is that if it is possible to train hearing to that degree in one person, it must occur in other people and therefore audio reproduction that is incapable of reproducing nuances at the required level and subtlety aren't capable of satisfying that fraction of those other people who DO want to build a home theatre with sound to make an IMAX manager cry.
Does it need to look good? Most home theatres are dim or dark, so provided it is in some sort of minimalistic cabinet, nobody is going to see it.
Totally immune to EMP. Besides, we need people to magnify the Casimir effect if we're to ever get wormhole technology. And, trust me on this, you do NOT want an evil general on the other side to go around suppressing it when you're half-way through.
Eleven?! Eleven was in style when Spinal Tap were around. My sound system goes up to 13, except on fridays.
It depends. Sound quality doesn't scale, generally, which is why standard speaker systems have vast arrays of speakers that operate over very narrow ranges. The sound quality using cones and magnets has gone as far as it can, short of moving to superconducting electromagnets.
There were some speakers demo'd on Tomorrow's World, way back when, which consisted of an electrode in a spherical wire mesh. The spark, pulsed at the right frequency, could generate sound. It was extremely high quality, far far higher than the Tesla Coil speakers you see on YouTube. But nothing ever came of the idea. Still not entirely sure why, but I suspect large amounts of ozone and the power you'd need to cross the gap they were using would make such a device uneconomic.
The nanotube idea is interesting, but I have a real concern that technology these days isn't about quality but quantity. Notice how the summary emphasizes the production of the system, but also observe how DVD lifespans are pathetic, hard drives have much shorter MTBF than earlier generations, MP3s largely replaced lossless codecs, digital cameras have a fraction of the effective pixel count of film, etc. Nobody wants high-end. They want crap that's tolerable and affordable. (Which also explains why Windows is a "success" and Linux has never made it to the desktop -- yet is the only serious OS in the few luxury/demanding markets left.)
It could be that nanotubes will prove to be capable of high-end sound, REAL hi-fi sound, but let's face facts. Even if it was, even given that the technology exists for 11.1 sound with an upper operating limit of 384 KHz at 24 bits, when was the last time you saw a CD with music recorded at that level? People want more tracks per piece of physical medium and would probably settle for 16 KHz at 16 bits resolution if it gave them a few more bonus tracks. There are audiophiles out there. I know. I'm one of them. Although, sometimes I think I'm the only one left. That depresses me, but you have to wonder. Purported audiophiles who can't tell what gives good sound and what doesn't clearly aren't audiophiles at all, they're blingophiles.
Next week, I'm running a class on brewing mead.
However, I shouldn't have much trouble getting a universal VM out a few days after that. After all, an OS itself is merely a virtual machine (a fact you've apparently forgotten) and writing a plugin framework that would allow bare metal drivers on one side and a collection of plugins to provide kernel level functionality on the other should not be hard. I don't need to have the plugins, beyond the minimum to offer a proof that I can run any set of system calls I care to write the plugins for on any set of hardware components I care to write the drivers for.
In fact, as several "bare metal" OS' already exist, as do several microkernels that allow OS' to be layered on top (ADEOS and L4 being two commonly-used ones), I probably don't have to do that. We already know Linux will run on any architecture for which an architecture module exists, so we know platform-independence is doable at the bare metal layer. Between the various experimental OS' out there, it should be possible to show that drivers doubling as abstraction layers (which are pretty common) can provide enough information for running the hardware to be efficient. (Think about how many abstraction layers Linux uses to go from a file open command to an actual hard drive operation. Yet that's very efficient.)
The main problem with writing a middle layer that supports multiple OS' is that different OS' have different internal data structures. Otherwise, from this basic starting point, anybody could write a generic OS in a weekend. What you can do, however, is have a layer that provides a whole bunch of different data structures that synchronize on write. You only need to refresh what's in use, so provided the userspace is kept simple, the kernel performance won't be killed, merely maimed. Since you don't actually have to care what driver does what, so long as what you want done is provided, we can start with Linux and simply write data structure converters for it.
How would this let you run OpenBSD apps? Or Windows apps? Or Solaris apps?
Well, what's in OpenBSD that isn't natively in Linux? pf and the filesystem. Oh, and the security, but if the NSA can remotely break into "any" box (as per the Guardian claim) then OpenBSD would need to have some exploitable flaw in the security, so for the people that matter, the security isn't necessarily that different.
Let's start with pf. There are two obvious approaches. First, you could take all the files from the OpenBSD source, create reflected structures that work with Linux' netfilter or the semi-mythical successor to it that will bear the unwelcome distinction of being released after Duke Nukem Forever, create the necessary header files and then essentially build pf as a Linux kernel module that operates inside netfilter. Not particularly efficient, as you're then partially running pf "natively" and partially running it as an emulated module. It would work, with enough time and effort, because ultimately logic is logic is logic.
By far the more practical method is to convert pf into a Z specification. Z is a bastard to work with, which is why most coders don't, but it's actually a very good way to clean-room implement something and know that you got the implementation 100% correct. (It's mostly a bastard because people are so inept at writing efficient code from specifications. However, if the specification is written from the code, it's already in a form that's efficient to code, by definition.)
Humans are staggeringly lazy. Nobody does anything unless they absolutely need to. This is why wars result in a lot of research and development being done. It's not because necessity is the mother of invention, it's because necessity is an axe-wielding psychopath that will slaughter anyone that doesn't do anything with all the projects, plans and papers that have been produced since the last war.
We need to explore the outer planets, less for the data that might be there (you can obtain the same volume of world-view-shattering data from many sources), but purely because it gives the engineers no choice but to actually get off their lazy collective arses and do something productive. (NB: I say engineers only because the managers are lost causes.)
Solar panels, no matter how good, won't help. All the sunlight falling on the entire of Jupiter would not power the computers, never mind ion drives, of an advanced probe, and there is simply no way of building solar panels larger than that. Lower power electronics are easy, we could do those tomorrow. Voyager 1 is running multiple instruments AND a long-range transmitter on a trace of power so low that most home multimeters wouldn't register it, and electronics are tens of thousands of times more efficient today than back then. (Further, if the probe is using an ion drive, you can store the data rather than sending it, which means you're not confined to bandwidth limitations or the horrible inefficiency of wireless.)
Reactors won't get lighter. Fission has gone as far as it can. Until someone develops working fusion, there will be no significant reactor development. In fact, most probes don't use reactors at all, they use nuclear batteries. Different technology.
Radio sensitivity won't help. Shannon showed that the retrievable information (even in theory) is not dependent on the sensitivity of the receiver or the power of the transmitter.
Mining asteroids is a waste of time. The cost will always exceed the benefit, even if you parked an asteroid made of solid gold in Earth orbit. Even if it could be made profitable, it merely encourages a waste of resources, and it is because humans waste resources so much that R&D never gets done until it's past too late.
Sending up better telescopes is seriously stupid. Crystals form better in microgravity and you won't get the mirror deformations that hindered Hubble so much, if you just build (from raw material) the entire telescope in space. In fact, park a disposable construction facility in orbit around the moon and you'd be able to build a defect-free optical telescope in space larger than the largest radio telescope on Earth.
Balloons to Venus would tell you nothing - we've already got a fairly decent surface map and the atmosphere would destroy any material you sent. No, if you send a probe to Venus, the only rational place to send it (and the only place we'd get new data) is below the surface itself. That means taking a small asteroid, putting your probe in the middle, then slamming the lot into Venus at a speed that'll vaporize most of the asteroid and put the rest plus probe deep enough underground to actually do real science on the planet prior to the utter destruction of anything left. This is way, way beyond what we can currently do, and even if it wasn't, we've far more to learn from asteroids than from Venus. Venus is a boring planet.
Mercury is also a boring planet. It's basically a lump of iron ore, with a few traces of other metals thrown in. Pretty much what you'd expect, given that the rotation of the accretion disc would have separated out the various elements very efficiently (which is why you see the types of planets where you do) and also given that Mercury shows strong evidence of being a planetary core with the outer parts of the planet blasted off at one time or another. It can tell you about planetary cores, if studied as a whole, but if you're limited to a few mm below the surface of two tiny, non-representative regions, then it can tell you nothing at all.
We already know from Doctor Who (Second Doctor, second story featuring the Ice Warriors) that humanity doesn't get beyond the moon until after transmat and weather control have been developed and we have a fully operational moonbase. Although the transmat part looks like it may be doable (despite incorrect calculations by cynics on how much data would be required), we're probably not going to see a moonbase and weather control is likely an impossibility.
Since these are prerequisites, I conclude that further travel than that will not happen. Since nobody will be going further, there will be no need to explore further. Whether, as Douglas Noel Adams' suggested, it turns out that leaving the oceans was a really bad idea is hard to say, but the lower 95% of the population seems determined to convince me that it was.
I program natively in more languages than you've had hot fixes. I've probably run more Linux kernel projects than you. And judging from your UID, I've roughly a thousand times the experience of software development.
By 99.5% the same, I do not mean implementation (which is immaterial and gets in the way of real work) but design. If you regard no function as a null function, then all OS' have a memory management API. It doesn't matter if it's the DOS idea of memory management (if it collides, it collides - survival of the fittest), the Linux idea (where there's compartmentalization, memory mapping and System V shares) or some other scheme. It's just an API for a black box.
And that's the whole point. Yes, there are modular OS' (Linux), monolithic OS' (OpenBSD), microkernels (L4) and even nanokernels, but that's architectural bullshit for the most part. For any given function in any given OS, there will be another OS in which you will need zero or more functions to perform the same task. But it will be performable.
The "ideal" is to write a pseudo OS - done these loads of times, they're fun - that performs all of the core operations you need in all OS'. (Games, for example, don't generally need to access the print spooler or OS-level password table much.) This pseudo OS can be written as a library and included by a compiler or cross compiler. (This is how Occam, Java and Smalltalk work, I'm not certain but am fairly sure it's how the Ada runtime works as well. Wine partially operates this way, as did the long-lamented IBCS2 module, but you're too young to remember that.)
The pseudo OS would have the same split as GCC - frontend that the user experiences and a backend that the machine experiences. In this case, the backend would be the ties from the pseudo OS to the actual OS you're running on. Which, again, is really how GCC works. I repeat myself. I need to. There are so many dumb users these days.
Anyways, that is how you make it possible to write one program for one environment and have it run everywhere. It is very very simple, it has been done many times, I would write another but I'm busy this weekend. Besides, you've not learned the ones that already exist, so why the hell should I write you another to prove the point?
Ideally, since a language IS just a virtual environment (it's not a real one, it's converted into a real environment) then your pseudo OS could be a programming language. Since libraries can be added to libraries, you can then build up the environment as far as you like, knowing that cross compiling to any supported OS will still work 100% of the time.
Thus, if you have a truly standard C compiler with true portability libraries for what you need but don't find in C, you achieve the precise result I describe. But, no, you'd rather whinge about how it can't be done, and how those who actually do this stuff can't really be programmers. Sorry, I learned programming before you learned how to subdivide your cells. The reason I consider coders these days to be complete wazzoks is that they don't understand any of the theory or how the theory applies to the practice.
NEVER trust the odd numbers. The even number patch releases are where they fix the problems with the odd number patch releases.
Basically, Microsoft is dealing with multiple Operating Systems for which no complete design document exists. For any of them. Microsoft is highly departmentalized and, in consequence, it is impossible for Microsoft to compile a single design for the entire system. They simply don't have the structure.
This is not necessarily a bad thing - things tend to be worse when unrelated subsystems start making assumptions about internal design that they shouldn't. It simply means the Windows environment is now too big for a corporation to manage. Microsoft has exceeded its maximum stable size, and has done for some time. (Based on quality of products, I'd say somewhere around the DOS 4.0 level, but that would be mean. Accurate but mean.)
The only reason I use MS products at all is that application developers go out of their way to be burdensome to non-MS users. Wine has a terrible time with many Windows applications and that's about the only way to run them at all. I would truly love developers to push platform-specifics into a library. It can be done. They can then either write libraries for other OS' or provide the API to that library so that others can write a porting library. It's not like it would hurt sales and it won't affect the game because it's purely a support module.
But, no, game companies and solo writers prefer their 1970s approach to coding - damn the portability, even if all OS' are 99.5% the same, and damn the sales, we want absolute totalitarian power! Bwahahahahahahahaha! Even if it'll eventually kill the product and the company. Who cares, when you're rich, powerful and utterly FUBAR!
Not just American. The Fashion Industry uses it for both clothing lines and supermodels.
Picture this. The Federal Government buys up dark fibre, or lays new fibre, such that there is a "Tier Zero" multi-path network between significant population centres regardless of State boundaries. Tier 1 ISPs can hook into this but the Government's networking is transparent so ISPs can't charge for traffic distance. Tier 1 ISPs aren't obliged to do so, though, and in either case this would not alter any peering agreement between Tier 1 providers. All it would do is provide extra stability, extra bandwidth and extra reach (Tier 1 ISPs could, via such a Tier Zero network, form peer-to-peer agreements even when a hostile Tier 1 geographically isolated the two).
Extra stability would cut Tier 1 costs (fast maintenance costs money, this would buy time for the Tier 1 to make quality repairs rather than cheap, natty repairs) but this would require the Government to charge for "diverted traffic" in a way that would make it cost-prohibitive to simply use the Government network and ignore their own but cost-effective as a way of handling the bursts the Tier 1s can't cope with without expensive upgrades. That's not getting support, that's becoming a parasite.
State Governments would then be allocated money specifically to connect schools, colleges, universities and accredited research centers (or to boost speeds where connections exist, or to offset costs if the speed is perfectly fine), and to build metropolitan mesh networks (at the wired and wireless levels) with support for Mobile IP (since users can be expected to move from node to node). This need not affect ISPs, as most of their customers are in the suburbs/sprawls anyway and the cost of laying down or replacing high-end hardware under city roads is going to be high enough that the profits there will be eaten into very quickly. What it does do is free up ISPs to reach customers further out where access has traditionally been poor. Not that they will, but they could. Customer-level ISPs wanting to remain in cities because they can add value would obviously be able to.
Virtually everything would remain private, except for those areas where individual companies don't have the means and/or motive to do the job right.
The level of security doesn't change, since the ISPs are all pwned by the NSA, you wouldn't get coast-to-coast disconnects due to a single fibre being cut by accident, and a city-wide mesh would speed up access to local information. Government would do what it does best and industry would do what it does best. So, naturally, everyone would complain.
I agree completely with your post. In essence, it boils down to Critical Path Analysis. The fastest a given page or data set can be delivered is equal to the speed of the critical path through the system. When you have heapsloads of parallelism, the critical path can span multiple threads and in some cases be impossible to determine.
My approach to layering is to simplify the CPA, make responses more deterministic and less vulnerable to accidental deadlocks when related pages are simultaneously accessed. That, alone, speeds things up.
Yes, PostgreSQL in charge is good, the lowest level is operating as a powerful pre-fetch that can also act as a sanity check to ensure reads don't write.
If a network fails before the system, then your system cannot fail in a distributed denial of service attack. Since any decent data centre multipaths, the failure of a network is of no significance.
Hey, wait! I am a 4 digit UID who has published code since the late 1970s! What the hell do I need to explain to some 6 digit street urchin? Face facts, you are nothing more than semi-evolved slime with the IQ of a desiccated dung beetle. You want to harass an old-timer? You think your pitiful excuse of a right-wing troll is worthy of consideration? Pffft!
As for your username, Wumpus is probably as intellectual as you can handle. Even a desiccated dung beetle has enough joints to handle the state space.
We can continue this on alt.flame, assuming you don't confuse that with a URL.
I mentioned NoSQL databases (so no marks for observation). The reason for the two layers of RDBMA is that you get a lot of potential blocks by loading everything onto one layer. Worse, you get heavy resource drainage when any serious crunching is done. One system I worked with took 5-6 minutes to complete a particular SQL query and often timed out. I refactored it down to 25 seconds, but that was far longer than I wanted. The tables were huge, swamping the database's caching capacity. The stored procedures were vast, even after refactoring. Intermediate tables were generated by other stored procedures. Moving those intermediate tables and related procedures to a different engine meant they could be fresher without killing the system, and since these tables were now views and not raw tables on the second tier, the security was better. Access times dropped to around 7 seconds.
So the three tier layout using some permutation of NoSQL/memcache, PostgreSQL and MySQL/MariaDB, for extremely heavy loads, is superior to trying to get one engine to digest everything.
For very light systems, obviously multi-tier systems are not going to be efficient. Each layer adds latency, and each layer that has excess capability adds latency. You want the lightest system that'll do what you want.
I started in the late 1980s on gigabyte databases, and they've only grown in size and complexity since then. Back then, I was asked to make the system handle real-time data streams from large gamma ray detector arrays. Which I did. I also managed to show that their network would suffer a meltdown before my software. My approach has been refined, over the years, to include understanding of different topologies (and how to thrash them into submission by writing custom high-performance network protocols), but my personal objective remains the same: there is no way in hell I will let my software suffer a meltdown before your hardware. My software WILL take the punishment you throw at it, give you the results AND complete The Times crossword before you've had time to register that you sent the query at all.
Because I know I can do this, I have little or no regard for programmers who cannot or will not. Anything I can do, they can do.
I've probably shipped more code than you'll run in a lifetime. What's more, it's damn fast code, highly robust and damn-near DDoS-proof. You? Pffft! Your comprehension of systems is only marginally superior to your comprehension of quantum gravity.