How do you join one table to another when they are on two separate boxes?
Several people have asked this question. Have you looked at the white-paper? It's possible to do RAID-1 which is m fully redudant DBs with all tables being fully accessible from a given DB. In RAID-1, therefore, there is "zero" problem with joins / updates / transactions, because it's literally just pretending to be accessing a single machine.. (I quoted zero because you might have synchronization issues if one machine somehow responds differently to updates).
Not having looked at the code, it would seem that the Raid 0,2 solutions would require at least seperating tables based on lack of Foreign key references and potential joins. I am guessing that you can't do the joins, (or at least not do them efficiently if the controller is actually munging the data). The key, however is that you - the admin - are choosing which tables go on which machines. So we're not talking about truely striping the data as in RAID-0 where pseudo-randomly some data goes here and some goes there without user intervention.
There are a ton of deep issues beyond just making the different partitions transparent to the application level. Think about joins across partitions for sec...
Don't see how it limits you here. If you have n fully redundant RDB's, a single controller, and m clients, the dispatcher load balances you such that if all m clients are performing non-destructive reads, they all read from different machines.. (preventing resource starvation). Each machine either put everything on one disk or segments the data across multiple disks (by table, or otherwise). But the key is that all DBs do this the same.
As for writes, that "shouldn't" be a problem either, since all you need do is simultaneously (via multi-threading) perform a write-request to each machine. It shouldn't be any different than if there were only a single machine.
The only caveat is when two machines don't respond identically.. But if the machines are fully redundant (similar hardware/disk space/memory space) then I doubt that would happen (obviously it's not impossible though).
I can see problems such as if a C-JDBC connection is cancelled or the controller crashes, then the databases could be left in a bad state (with some DB's completing sooner than others).
Theoretically, the controller could use a redundant journaling system to recover (knowing what to "try" and rollback).. Moreover, cancelled c-jdbc connection can simply try and complete their tasks, reguardless of the connection problems (this is a policy issue). But a crash in the single controller could be akin to a crash in the database - warrenting some manual data-recovery.
I'm not saying that there aren't deep issues, but at least I don't see weight to your join problem.
The issues that DB2/Oracle run into are making clustering transparent. c-jdbc is already demonstrating some API limitations. So it's obviously not a general purpose solution.. But it still suites many needs (Code, Fast, (/good))
There already is clustering support in postgres via triggers. Problem is that it's still alpha/beta.. The problem (as other replies have stated) is that the job is nefareous, and it's possible to massively corrupt the data.
Think of RAID as it's hard-drive counter-part.. Data-integrity could be most efficiently handled at the hard-drive layer.. Having multiple redundant controllers and disks, etc. It would be a generic disk as far as the SCSI/IDE card was concerned.. But it turns out to not be the cheapest solution. Having several "cheap" fully redundant (in terms of controller and IO/cables) machines with a relatively simple redundant dispatcher works very nicely. The fact that you can use proven off-the-shelf drives is also a boon.. You don't have to pay for low-volume high-value (and thus high cost) drives which may not even be supported 10 years from now.
The same is true with database clustering.. If you choose postgres clustering solution A.. It may lose support (in a feature-lacking state) and you'd have to port your data to solution B later on.. Moreover, you restrict yourself to the types of operations you can perform.
Theoretically by making fully redundant lower layers, your system is as reliable as the lowest layer in a simple-mode (which is generally pretty reliable). Moreover, thanks to JDBC, you can swap out entire databases without changing your API.
It is true that swapping C-JDBC to something else requires a code-change, but remarkably, not a database-format change. We don't have to worry about "upgrading" the clustering triggers or any of that mess. Moreover, my first glance suggests to me that c-jdbc is jdbc-like and thus shouldn't be too bad to swap out with cluster-solution B.
If we were doing clustering at the database level, we couldn't use the RAID mneumonic, since in many respects it wouldn't be "Inexpensive" (at least in terms of development/maintainance time).
I can't imagine that dot-files and space'd file names are anymore a problem.
Namely: alias ll='ls -la --color" and tab-completion.
While it's true that.gnome/ and.kde/ subdirectories could be havens for nasty files.. So could/var/tmp,/var/spool/mail, or any other hidden publicly writable directory of any OS.
I haven't read the book, so I can't comment on any other 9 year old complaints.
But remember, lazy programmers make good programmers. VB's simplicity means business types don't need to "bother" specializing in programming to perform advanced macros (or crappy web sites).
Java/C# is a more robust language than c/c++ (in my opinion), but allows us to lazily ignore resource management (which has it's pros and cons, but mostly cons), and also is designed to be interpreted (even jit's can't fully transcend the interpreted dynamic loadabled runtime API).
Further, "lazy" also applies to the newer and newer graphical abstraction routines, which go back and forth between enabling more graphics cards to work with the advanced graphics of new games and slowing the begeezus out of our systems. These abstractions are mostly because software developers don't want to rewrite their nifty effects to work properly on every graphics card.
Abstraction is all fine and good, but it's only there for lazy purposes. And the cost is almost always performance.
Poor programming is when we choose lazy solutions over specialized solutions when only cost is the knowledge of an API. (e.g. applying VB/Perl/Java to every problem)
That being said, given that human resources are expensive, I'll take faster machines and slower programs any day.:) You can always profile an app.
I'm unsatisfied by the idea that hardware is cheaper than developer time. Word Perfect alledgedly attempted to make a version in java, but scrapped it because of speed concerns.
If your product just barely runs within an acceptible time-frame, then you confronted with the probability that a given customer will agree with you. If a customer doesn't agree, then they will not use your product.. Thus while you save money on developer time, you lose potential customers (or existing ones). Worse, late in the game (after spending significant R&D time), management may decide to scrap the project when performance doesn't cut the mutards.
Yes, I realize that there are full-fledged GUIs written in java (Idea/eclipse/etc), but I definately notice their performance penalties (even on a 2GHZ machine with 0.5Gig mem). Moreover, the memory isn't enough to keep these monsters happy.
Now imagine a work-station runing a dozen java apps, each taking up a majority of the CPU. Current hardware can't even support this sort of environment without some hair-pulling.
Moreover, the idea that you can "throw hardware at it" assumes a certain level of parallelizability. Some problems are inherently serial and there is a definate max performance a single thread can achieve in a given generation.
Moreover there is an incredible danger in sacrificing performance to the hardware gods.
We're going to assume for the moment that we're talking about real developers here and that the idea of O(k), O(n) and O(nlog(n)) are religiously adhered to.
Assume that a given method is a k times slower than it could be for a given environment (where k need not be an integer; e.g. allowing 1.2). Now extend this process for an entire enterprise app.
Now realize that methods are generally part of loops, the delay is amplified. While the app may only utilize nlog(n), there are m such loops (where m grows as if n). Thus we have m^2 = (k*m)^2 => k^2.
Now if we only have k == 1.2, then we're fine, but since we have an interpreted environment, simple operation really take many times longer than equivalent c. Thus k is really 4 to 20 times it's conceptual cost. Thus k^2 => 16 to 400.
A java app has the potential to be 400 times slower than a c equivalent. Given the fuzzy numbers being used, I'll simply state that: An arbitrarily abstract language is capable of producing sufficient values of k that there exists a level of complexity of code that will produce wait times that exceed the performance capabilities of a given hardware generation.
In short, we can get carried away in abstracting the hardware and overcomplexifying the software to the point of self-destruction.
One good example was an [unnamed] JDBC driver that wrote very elegant object oriented code but unfortunately accounted for 90% of the CPU and memory load of neighboring application. The overhead was small but subtle. Each component allocated and threw away objects.. Each such operation required potential garbage collection and initialization. There was never anything more than O(n), but there were several such O(n) calls within a single JDBC method invocation. The k's compounded enormously.
The thing is that you wouldn't really notice the overhead if you only accessed the JDBC once or twice. Unfortunately we happened to utilize jdbc calls in loops, which exposed the innefficiency. By using a different driver (which performed optimizations such as utilizing a static StringBuffer to avoid ANY memory allocations) the JDBC overhead became negligable.
The moral of the story is to identify (at design time) critical loops AND critically accessed sections and consider performance.. This is profiling 101, but I hear more and more java-developers arrogantly transcend such problems.
You're forgetting that the entire bus architecture would be 64 bit.
Others have already said this but the BUS size is irrelevant.. This is obvious when you consider that SDRAM has a 64bit pipelinable bus, and everything from the Pentium on has had 64bit CPU bus's.
Moreover, bus size isn't as important as bus speed.. Otherwise Intel + Rambus wouldn't have created a 16bit memory bus (with frequencies insanely higher then the state-of-the-art at that time).
Moreover, I haven't looked at the details in a while, but I heard that the North/South/East/West bridges of the opteron will only be 16bit (most likely to minimize pin-out hell).
There wouldn't be any slowdown since there's no basis for comparison.
This topic has been battled back and forth. 64bit address size means 2x the code size for memory addresses (AMD acknowledges a 1020% code size increase).. This translates into more wasted cache space. This is worsened by the fact that pre-ops are required to maintain binary compatibility (wierd concept since it's in a new operating mode).
Moreover, it is incorrect to think that you can compute a 64bit number in the exact or (fantastically) in less time than a 32 bit number. Period. Now, clock speed is determined by the slowest possible operation you need to do in a clock-tick.. Thus, this might be the point that you suggest is incomparible. If a 64bit ALU op isn't going to be slower than say a register fetch or a certain stage of the floating point unit, then yes 64bit ALU won't be a bottleneck.. But remember, some parts of the CPU require doing an add as just one part (such as doing a memory fetch/store). This is especially problematic for CISC machines which potentially can do "add MEM1, MEM2, MEM3". HOWEVER, Intel's P4 definately would feel the effect. It double-pumps the integer ALU, so the slack-space is less avail.
Front Side bus mainly applies to memory hog applications (which of course the 64bit issue can applies to this as well).. But when we look at speedups for games such as counter-strike, what we see is that the speedup really comes from adding an extra set of registers.
What the x86 line needs is not more memory, cleaner instruction set, or better memory management, but more registers.
I'm somewhat upset that AMD didn't make it's x86-64 use 32 registers (the defacto standard these days). Morever, given that Intel added a ne w operating mode for use with SSE, I don't see why AMD couldn't have added one that merely provided the 32 registers for x86-32. They would have a HUGE jump on Intel with hardly any additional cost. Most compilers implement algorithms that are register-set-size nuetral, so it should not be a dramatic rewrite for anybody's compiler. Granted, you muck-up most of the op-codes, requiring more bits per register, but that's what the new mode is for.
Going to 64bit, otoh is an enormous change.. Not to mention, I don't believe AMD gives you the option of using the extra register without requiring 8 bytes per pointer (thereby losing the space-efficiency of 32bit coding).
While I'm happy to see any progress, I'm disappointed that the root-canal type changes that will be necessary to support x86-64 aren't going to bring the PC up to even 1990's technology standards.
The speed of sound in a medium is a function of the average velocity of the molecules in that medium. This is based off of the ideal-gas law, utilizing the probability of direction of particles bouncing off one another.. Collision of gas molecules against solidly compacted forces (such as the front-end of an ship (air/boat), an explosion wave-front, etc) merely causes the molecules to divert their direction, and such ping-ponging causes neighboring molecules to divert, thereby causing an effective motion of the gas. When a large body of such molecules move in the same direction (on average), we call this a current.
Wind is such a current, rivers are such a current, electrons propagating along a conductor is such a current. In each of these cases, a single particle (molecule/electron) is not moving the entire length, but the net motion of all the colliding and direction-changing particles is.
Thus, as with the speed of light, for net-aggregate-velocities (current velocity) much much lower than the average velocity of a given particle in the medium, you can use linear superposition. Namely, if you are in a car moving at velocity x, and you through a book forward at velocity y, then until air-resistance slows you down, the book will have velocity x + y.
However, as you approach the average speed of a particle in your medium, the particles on your wave-front can't move forward fast enough to "get out of your way", so the apparent friction becomes non-linear (polynomial, in fact). You are now accelerating the particles in front of you, and apparently gaining mass (as far as propulsion is concerned). BUT, the key is that you are accelerating the particles in front of you.
I believe the formula for friction in an ideal gas is something similar to: 1 - V^2/Vavg^2
Which is related to the lorenz contraction factor.
Ideal gas law does not mean that no particle ever travels faster than the average.. In fact, if enough energy is released into the gas such that it's temperature (e.g. aggregate kinetic energy) rises, the it's average velocity is indeed increased.
Thus my nitpick is that for the analogy where a repulsive force is sound and gravity is wind.. As your "wind" velocity increases, you are, in fact, increasing the average velocity of particles. Any perterbations (shock waves, aka sound), now can propagate faster, though in a non uniform manner (the direction of the wave will be faster in the direction of the wind (parallel direction), average in orthogonal directions and dramatically attenuated in anti-parallel directions).
Further, if the auditory devices (sound-generator, and target) are carried along with the medium, then their relative velocities will be constant with respect to the medium, and sound will effectively probagate uniformly.
There is one tiny wrinkle in all this. Here, the max velocity is consdered to be Vavg and is changable. In quantum physics, Vavg is the speed of light and can never be exceeded (at least on average). Thus linear superposition breaks down. Increasing the velocity of the wind means that particles ricocheting forward can't produce a net propagation velocity twice as fast relative to a stationary transmitter/reciever.
Theoretically, all the quantum "forces" are effectively energy moving through space and time at different ratios. Plotting them together as a 4D space-time plot, the magnitude of the 4D coordinate should always equal c. Thus if you are traveling along the event horizon at c in any one direction, then you should have no remaining ability to travel in any other directions (including time). Thus perterbing the medium should be impossible. The event horizon would be like having a steel shell that is oblivious to outside disturbances (ignoring that steel allows for elastic collisions, including sound). I speculate (as a lay person) that the reasoning that event horizon particles are oblivious to anti-parallel disturbances is because they have
While I acknowledge that the geometry radically alters in the presence of intense gravity (in fact, String theory suggests that the number of dimensions collapses inside a black hole to an effective singularity (though protected by minimum plank-radius)), I'm not comfortable using the phrase circumference to describe it's externally apparent dimensionality.
At the least, you'd have to consider the black hole as a 2D surface (or shell). Which is still related to r^2.
Only speaking as a well read lay person, I've heard black holes being described as 2D planes; all the mass exists within the event-horizon (since time slows down as you approach it, approaching the speed of light).
That being said I can almost comprehend space being warped enough such that the r^2 flatens out to r, but It's still beyond me.
Actually in 7.3 you can finally drop columns, fwiw.
I don't know about MySQL 4, but the biggest problem is that MySQL seemed to emphasise speed over robustness.. Large scale benchmarking in the 3-tree caused corrupted databases. postgres has had a journal for a little bit now (don't know how long though). Plus postgres's version-based rows allows for some really high performance parallel transaction control.
It all comes down to what you are really trying to do.. If you're willing to lose a day's worth of work, and you're not going to have more than a couple dozen simultaneous connections, then MySQL is probably good for you.
Perhaps 4 has allowed MySQL to catch up with Postgres / surpase it, but it's had too murky a history for a lot of businesses who rank data-integrity number 1.
Torque is a measure of the ability to do work. Foot-lbs means how many lbs of Force is applied at a leverage point of 1 foot.. It's the same as force, but in an angular orientation instead of a straight one.
Horse Power is the measure of Torque at a given RPM. Force in a given time is called power; the ability to do work "quickly".
Thus a truck have enormous torque and thus can have a really high horse power at low RPMs (namely lugging tons of material from a complete stop where RPMs are between 600 and 2,000). The problem is that the massive design of their engines do not lend to high rpms, therefore it does not scale.
Moreover, the engine itself has such impeedence that it just physically can't accelerate it's own engine's RPM, much less that of the entire vehicle.. So even if you took a truck engine and installed it in a geo, you wouldn't have a fast accelerator, though you WOULD make the tires spin for the first second.
In this analogy, other's have already said that the truck vers.s the geo analogy is probably more of what you're trying to say (at least with 32 v.s. 64 bits).
The torque v.s. horsepower is better suited to wide v.s. deep. A deep architecture (many parallel execution units) can do a lot of work (though this is independent of how fast it can do it). Deep allows a rapid "ramp-up", and can achieve incredibly high speeds (though it may not actually be getting any more total work done). Put another way, Instructions / clock (torque) and clocks / second (rpm), or Instructions per second (Horse Power).
With high Instructions / second, however, you have to differentiate between peek and sustained. The same is also true with width, but to a lesser degree.
Since your address word-size changes in 64bit mode, imagine the horrors of having different sizeof(void*) from function to function.
I can't imagine this something you'd ever want to do (what size would malloc return?).
Still, I can see a potential problem. If you have a Linux distribution, some binaries will want to be 32bit, and some will want to be 64bit (what other purpose would there be to having such a compatibility mode). But shared libraries (libc.so) would be really nasty.
I've read here that ELF can support multiple architectures, but you'd still have to compile the darned code twice for each shared library.
I know I just gave programming examples but a tool is a tool, and students should be given a wide variety of them so they can make the choice.
Furthering the base comment, a higher education degree is meant to teach you theory, not a practical trade. If you want a trade, go to trade school (which includes programming). The rationalle might be that if you feel like you know everything there is to know about something, you will cieze to ask new questions, or consequently make new discoveries.
The theory behind a dependency list is useful. The particular features of a given make-tool is not (in terms of theory). The idea of a GUI is useful, a particular IDE emacs/VS/idea/etc is not.
Moreover, we learn best by discovering on our own; therefore a good university only gives you the building blocks necessary for you to discover after the fact.
I remember our professors specifically using in-house libraries, languages and environments, specifically so that we wouldn't get pigeon-holed into learning how to use a particular brand of tools. We weren't even taught UNIX operations.. We were inundated with class-specific.cshrc files and custom macros/scripts.
It was only after a couple years that many of us students could discover the hidden powers of UNIX.. And even then, mostly through our peers. What a great preperation for the real world.. Especially since in the real world, we rarely have a managing professor that knows what the answer eventually needs to be.
Lets see some real binary code reuse in linux, and not this crap where App A needs libfoo1.1.so and App B needs libfoo3.4.so. If I need two different versions of the library for two different apps, guess what, that ain't code reuse.
Would you rather App A symply not work because App B's required libfoo3.4.so isn't backwardly compatible? Or would you rather have everything staticly linked?
Heck, half the time, libfoo1.1.so is a symlink to 3.4. I don't understand what your problem is.
I mean sue Microsoft when they break laws. Having a better product isn't anti-competitive. It is competitive, it's just that noone else is competing.
While in principle I agree with you (people should focus energies on outclassing MicroSoft), the reality is very different. The issue that has to be addressed is the barrier to entry.
1'st tier: Make an audio platform that can be used by 3'rd parties.
This would require that each apps that wants to use widget-class-X needs to be able to go fetch / download and install it without bothering the user. Any complications in this process are such that app developers won't want to be bothered or liable for the associated tech support. Thus, if there is a "standard" garunteed installation of widget-class-X, then any sane developer would use the default. Since MS ships many and eventually all widget-classes, the defaults are usually/always MicroSoft apps.
BUT, any such app is really just part of a widget-class. Thus any non MicroSoft producer is likely to not be purchased if there is already a bundled default.
The cycle repeats itself as MS includes more and more default widgets.. Now you may think this trivial for something like media.. Maybe you even think it's trivial for a web browser... How about a web server? How about a file-system diagnostics? So on and so forth.
Now you could argue that these attributes are part of the Operating Environment (OS is a tainted word). This is merely the platform for the "real" user applications. Like video games, office products, money/resource managers, etc.
But the next issue is application interaction. Media is regularly communicated between different PC's.. Via email/sneaker-net/etc. The format of that media MUST be compatible.. Thus either you need an application that can render the media or you need to own the same software-vendor's media-package.
By media, I'm actually speaking of word-processing, spread-sheets, presentors more than jpg,.avi,.wma. There are plenty of popular tools to generate.png/.jpg/.mpg, and windows actually supports these formats. More-over there are currently no proprietary "extensions". But word-documents are the foundation of the work-place. The fact that MS won in the office wars is not a problem. The fact that the format of office documents is not reliably renderable on peer machines is the problem.
The reason MS is the champion of office apps is because they killed off their competition, and they've managed to get people to regularly upgrade to the latest version.
They way they do this is through lack of backward compatibility... If userX upgrades office; they'll generate documents that are not renderable by other peer users. Thus what often happens is that other users are greatly encouraged to upgrade as well.
Likewise, competing WordPerfect or what-have-you is generally incompatible and thus TCO is reduced if only a single vendor is consolidated to..
Thus their monopoly developed out of a cripling of one of the points of an application; interfacability (being interfacing with the user or other apps).
To be fair, it is unlikely that they went too far out of their way to hold a proprietary format.. It is more the fact that they didn't abstract the document format from the rendering process. (Embedded links to applications). I'm sure they made a contious design decision to lock customers in, however.
The problem is that once a person is has something that is adaquate, they will be unwilling to replace it was something completely new.
The end result then becomes an unregulatable monopoly. This monopoly allows them to basically tax every computer-bering man-woman-and-company on the face of the planet.. That in turn gives them enough resources to hire large numbers of "talented" people. Which in turn allows them to more quickly write widget-classes to encroach into ever newer markets, persisting the cycle.
The problems for the end user are that we're basically semi-willing citizens of an software dictator.. If they charge more money, we're forced to pay (their military is the BSA). If they break compatibility and successfully promote a version upgrade in one segment of the world, eventually everybody must upgrade to follow sute; and thereby pay their MS-tax. If they want to police you (as in 1984) then they are fully capable: (media player CD-title taddle-taleing, Win-Update installed-software taddle-taleing, and lord knows what-else).
Our lives within the computer are litterly based on the whims of MS. The only thing that prevents them for doing more to subvert us and charge more from us are practicality measures.. Suppy and demand limits their fees (but they grow as much as as fast as they can), policy viability (Their hailstorm failed in it's first attempt).
MS MUST be checked somehow, and it is unlikely to be viable through competition. Even if we wanted to, we could not all migrate to Mac's (the next most practical alternative). The application base just isn't there.
These words make me cringe like you cannot believe.
I know and I appologize for bringing it up.. But since I've already gotten you to this level of interaction. I'll press my luck.
Surely there is no end to the interpretation of the writings of Nostradamus...they happen to be confusing and oblique from almost any perspective.
Agreed, I was referring to both "prophetic" works.
However, if you again are referring to the book of Revelation, there is very little that is up for "interpretation."
Wow, this was the kicker that made me want to reply. I've never actually met someone that felt this way.
In fact, I recall going through a very interesting "interpretation" which suggested that the entirety of Revelation was meant for the times and life of John and Christianity's great tribulation: Nero Caesar.
Not speaking greek, I can't attest to the "clearity" of which you speak, however I have gone through books that had greek on left, english on right, and was not as convinced as you.
As for the rest, I'll merely say that I have a problem with the phrase "undisputed" in relation to anything biblical. To attest to the correctness of a work is one thing, but to suggest that no-one has presented serious and succesful logical opposition is straining credibility. A work that makes an untestible claim is not free of scrutiny. It is no more "correct" than fiction.
Generally the entire period is considered to be more than a few days, and contain more than a few tragedies. Exact timing, however, is somewhat of a farse. There are references to thousands of days and thousands of years being interchanged. You'd be hard press to interpret the timing literally (7 days of creation anyone? Or how about the Jehovah's Witnesses?)
That being said, I was actually more focusing on interpretations I'd read on Nostradamus.. It's been a while since I'd studied revelations.
I'm almost sorry I brought it up though, because this is a matter of faith (or lack thereof) and there's no end to such interpretation.
In a war people are violent, often long after the war. But that's more than just the collapse of society, that's an extension of society's self-destruction. Few apocolyptic scenarios involve mass societal collapse as a cause..
Step 1) Shock/Fear: Mass fear (will might die, my family might die, where will I live?, what will I eat?).
Step 2) Hysteria: People vauling their families or in worst cases, themselves over anything, including common human decency (trampling over people, driving over people, etc). At this stage, we become primally instinctive; we're in self-defense mode.. We're not able to think rationally.
Step 3) Anarchy: Hysteria slowly calms down.. We're no longer screaming (though many are still crying). Depression will start kicking in for some.. Many will lose hope. Many will start to think about the future. They'll quickly rationalize lawless activities. Rape, looting, general acts of violence.. People will chant the "end of the world", and try and live out their fantacies.
Step 4) Pragmatism: As the remaining loyalist military/police kills off the most violent offenders, the more remaining people are in three camps.
a) The "victims" that will not be able to recover on their own; they will need to be followers.
b) The "leaders", these will be people that will try and help out; working through the wake of disaster. These will be the optimisits. Being somewhat altruistic, they will fight for what they consider right, even in the face of dispair.
c) The selfish. These are people who will quickly surmise that it will take decades (if ever) to recover, and in the mean time, we will be living in the stone age. There will not be enough resources to sustain the remaining levels of population. Fresh water will be virtually non-existant due to polluting drainage, and lack of pump-work. Rain-water is likely to be hazardous, and possibly droubting. Thus the selfish will realize that if they forcibly coerse other's, the "leaders" (including the military) will have them killed. Thus they will subtly backstab, usurping power (at least within their community).
The problem is that only those smart enough to survive will become leaders. But as a follower, you can't be sure that your local leaders aren't secretly maliscious.
The fact of the matter is that people will die due to shortages, and in the face of this, the majority of people will act accordingly, even in the long run.
This will continue until either the population has dwindled to a sufficiently small group (which is unlikely given the then-newly-encouraged birthrate), or complex and corrupt power-systems will develop, which can contain the selfish class. Tyranical Dictatorships are the only systems that can contain anarchy. It is only given enough time and prosperity that benevolant systems can prevail.
In short, we're talking hundreds if not thousands of years to rebuild society.
If you're into apacolyptic tales, Revelation and Various profits (Nostradamus, etc) tend to talk about an apocalyptic aftermath which takes hundreds or thousands of years. So in short, I disagree that a cataclysmic event would have to be radio-enduced.
Sorry, but tablet PC's, notebooks and especially PC's don't match the readibility of the printed page. At least not yet.
The printed page allows you to cheaply have a group meeting where individuals make annotations, read-ahead / reread-behind independently of the presentation. An electronic device per person assumes interconnectivity (real issue when you're dealing with 3rd parties), and availability. (Company-wide meetings don't do well for providing every intern a laptop).
Also, I've yet to see a pen-style aparatus that's as easy to use as pen+paper. Putting your brain down on paper requires artistic freedom that the rigid uniformity of typed-text or even paintbrush-style apps can't yet provide.
If you're at school, it's unlikely that all your classes will allow e-submissions of your works. Especially if they're handing out form/exams for which to fill out.
If you're trying to comunicate with older relatives that boycott computers (yes there are still many alive and kicking), it's an absolute necessity.
Paper is still an order of magnitude more compact than a laptop (which generally desires tons of accessories). Personally, I still boycott laptops. The only requirement is to make sure that every place that you frequent have net access.
The paperless office was a pipe-dream - As the saying goes - If anything, computers have grown the requirements for paper many fold.
This isn't to say we shouldn't strive for it. Just that the lexmark issue is very real; especially given the clientelle of lexmark (budget minded home users and students).
I agree with you somewhat, BUT your argument is not very good.
if companies like Lexmark are allowed to decide what manufacturers are allowed to sell supplies for thier printers what is to stop car manufacturers from forcing car buyers to purchase specific types of gasoline or oil?
and
What's the next step? Only being allowed to you Lexmark approved paper in your printer?
The issue is that gas and paper are not under the controlling interests of auto manufacturers nor printer manufacturers.
The specific inkjet nossel, or toner cartrage is highly customized to fit the particular printer. Thus it's entirely possible to use the DMCA to conceal the API, or the patent the particular usage of the device. Someone that makes paper can do so for any number of printers; and thus can't have an injunction. Someone that goes out of their way to produce a cartraige that fits a particular printer has an obvious intent, and thus is at least susceptable to court harrasment.
What Lexmark and friends do is put 90% of their technology into their print-head. This makes the design slightly more expensive but it garuntees that you can't take advantage of alternative vendors.
Actually, if you read the article, PCI and ISA can still be supported. ISA is supported on current PCI boards through a host-to-host-bridge. Likewise, the new architecture can support PCI, and there's no reason to think ISA couldn't be supported.
The issue is that such a bridge costs money and space. The majority of people purchasing new computers (with no intent on upgrading HW) will want the cheapest, most-compact solution. This is the problem that faces video card retailers. They'll ahve to carry two lines of video cards (3 if they seriously still sell PCI versions), and they'll have to conflict amongst themselves as they market different HW. Especially in the months leading up to the roll out.
No word on whether AMD boards have any chance of supporting the new BUS. If not, then AGP cards will persist for some time.
Java is dynamically typed - that's why it defines things like a ClassCastException.
That's a perversion of the words dynamicly-typed. ClassCastException is similar to c's dynamic-linking errors.
Perl/Scripting languages are dynamically typed, not because they can load modules at run time (which just about every language I've ever heard of can), but because they auto-declare variables, because you can create/modify code at run time as part of the native language. The symbol table of perl is nothing more than a modifyable hash-table (except for lexically typed variables (my $foo)). This includes variables, functions, "magic" symbols, etc.
Yes, Java does have reflections, which allow completly dynamic interaction, BUT, would you write any substantial fraction of a program using this? This was an exception to the original java-rule-set, which allowed for greater total flexibility, but I would be hard-pressed to call Java Dynamic because of it.
Slashdot Mirror
How do you join one table to another when they are on two separate boxes?
Several people have asked this question. Have you looked at the white-paper? It's possible to do RAID-1 which is m fully redudant DBs with all tables being fully accessible from a given DB. In RAID-1, therefore, there is "zero" problem with joins / updates / transactions, because it's literally just pretending to be accessing a single machine.. (I quoted zero because you might have synchronization issues if one machine somehow responds differently to updates).
Not having looked at the code, it would seem that the Raid 0,2 solutions would require at least seperating tables based on lack of Foreign key references and potential joins. I am guessing that you can't do the joins, (or at least not do them efficiently if the controller is actually munging the data). The key, however is that you - the admin - are choosing which tables go on which machines. So we're not talking about truely striping the data as in RAID-0 where pseudo-randomly some data goes here and some goes there without user intervention.
There are a ton of deep issues beyond just making the different partitions transparent to the application level. Think about joins across partitions for sec...
Don't see how it limits you here. If you have n fully redundant RDB's, a single controller, and m clients, the dispatcher load balances you such that if all m clients are performing non-destructive reads, they all read from different machines.. (preventing resource starvation). Each machine either put everything on one disk or segments the data across multiple disks (by table, or otherwise). But the key is that all DBs do this the same.
As for writes, that "shouldn't" be a problem either, since all you need do is simultaneously (via multi-threading) perform a write-request to each machine. It shouldn't be any different than if there were only a single machine.
The only caveat is when two machines don't respond identically.. But if the machines are fully redundant (similar hardware/disk space/memory space) then I doubt that would happen (obviously it's not impossible though).
I can see problems such as if a C-JDBC connection is cancelled or the controller crashes, then the databases could be left in a bad state (with some DB's completing sooner than others).
Theoretically, the controller could use a redundant journaling system to recover (knowing what to "try" and rollback).. Moreover, cancelled c-jdbc connection can simply try and complete their tasks, reguardless of the connection problems (this is a policy issue). But a crash in the single controller could be akin to a crash in the database - warrenting some manual data-recovery.
I'm not saying that there aren't deep issues, but at least I don't see weight to your join problem.
The issues that DB2/Oracle run into are making clustering transparent. c-jdbc is already demonstrating some API limitations. So it's obviously not a general purpose solution.. But it still suites many needs (Code, Fast, (/good))
There already is clustering support in postgres via triggers. Problem is that it's still alpha/beta.. The problem (as other replies have stated) is that the job is nefareous, and it's possible to massively corrupt the data.
Think of RAID as it's hard-drive counter-part.. Data-integrity could be most efficiently handled at the hard-drive layer.. Having multiple redundant controllers and disks, etc. It would be a generic disk as far as the SCSI/IDE card was concerned.. But it turns out to not be the cheapest solution. Having several "cheap" fully redundant (in terms of controller and IO/cables) machines with a relatively simple redundant dispatcher works very nicely. The fact that you can use proven off-the-shelf drives is also a boon.. You don't have to pay for low-volume high-value (and thus high cost) drives which may not even be supported 10 years from now.
The same is true with database clustering.. If you choose postgres clustering solution A.. It may lose support (in a feature-lacking state) and you'd have to port your data to solution B later on.. Moreover, you restrict yourself to the types of operations you can perform.
Theoretically by making fully redundant lower layers, your system is as reliable as the lowest layer in a simple-mode (which is generally pretty reliable). Moreover, thanks to JDBC, you can swap out entire databases without changing your API.
It is true that swapping C-JDBC to something else requires a code-change, but remarkably, not a database-format change. We don't have to worry about "upgrading" the clustering triggers or any of that mess. Moreover, my first glance suggests to me that c-jdbc is jdbc-like and thus shouldn't be too bad to swap out with cluster-solution B.
If we were doing clustering at the database level, we couldn't use the RAID mneumonic, since in many respects it wouldn't be "Inexpensive" (at least in terms of development/maintainance time).
I can't imagine that dot-files and space'd file names are anymore a problem.
.gnome/ and .kde/ subdirectories could be havens for nasty files.. So could /var/tmp, /var/spool/mail, or any other hidden publicly writable directory of any OS.
Namely:
alias ll='ls -la --color"
and tab-completion.
While it's true that
I haven't read the book, so I can't comment on any other 9 year old complaints.
Java / C# / VB => lazy programmer..
:) You can always profile an app.
But remember, lazy programmers make good programmers. VB's simplicity means business types don't need to "bother" specializing in programming to perform advanced macros (or crappy web sites).
Java/C# is a more robust language than c/c++ (in my opinion), but allows us to lazily ignore resource management (which has it's pros and cons, but mostly cons), and also is designed to be interpreted (even jit's can't fully transcend the interpreted dynamic loadabled runtime API).
Further, "lazy" also applies to the newer and newer graphical abstraction routines, which go back and forth between enabling more graphics cards to work with the advanced graphics of new games and slowing the begeezus out of our systems. These abstractions are mostly because software developers don't want to rewrite their nifty effects to work properly on every graphics card.
Abstraction is all fine and good, but it's only there for lazy purposes. And the cost is almost always performance.
Poor programming is when we choose lazy solutions over specialized solutions when only cost is the knowledge of an API. (e.g. applying VB/Perl/Java to every problem)
That being said, given that human resources are expensive, I'll take faster machines and slower programs any day.
I'm unsatisfied by the idea that hardware is cheaper than developer time. Word Perfect alledgedly attempted to make a version in java, but scrapped it because of speed concerns.
If your product just barely runs within an acceptible time-frame, then you confronted with the probability that a given customer will agree with you. If a customer doesn't agree, then they will not use your product.. Thus while you save money on developer time, you lose potential customers (or existing ones). Worse, late in the game (after spending significant R&D time), management may decide to scrap the project when performance doesn't cut the mutards.
Yes, I realize that there are full-fledged GUIs written in java (Idea/eclipse/etc), but I definately notice their performance penalties (even on a 2GHZ machine with 0.5Gig mem). Moreover, the memory isn't enough to keep these monsters happy.
Now imagine a work-station runing a dozen java apps, each taking up a majority of the CPU. Current hardware can't even support this sort of environment without some hair-pulling.
Moreover, the idea that you can "throw hardware at it" assumes a certain level of parallelizability. Some problems are inherently serial and there is a definate max performance a single thread can achieve in a given generation.
Moreover there is an incredible danger in sacrificing performance to the hardware gods.
We're going to assume for the moment that we're talking about real developers here and that the idea of O(k), O(n) and O(nlog(n)) are religiously adhered to.
Assume that a given method is a k times slower than it could be for a given environment (where k need not be an integer; e.g. allowing 1.2). Now extend this process for an entire enterprise app.
Now realize that methods are generally part of loops, the delay is amplified. While the app may only utilize nlog(n), there are m such loops (where m grows as if n). Thus we have m^2 = (k*m)^2 => k^2.
Now if we only have k == 1.2, then we're fine, but since we have an interpreted environment, simple operation really take many times longer than equivalent c. Thus k is really 4 to 20 times it's conceptual cost. Thus k^2 => 16 to 400.
A java app has the potential to be 400 times slower than a c equivalent. Given the fuzzy numbers being used, I'll simply state that:
An arbitrarily abstract language is capable of producing sufficient values of k that there exists a level of complexity of code that will produce wait times that exceed the performance capabilities of a given hardware generation.
In short, we can get carried away in abstracting the hardware and overcomplexifying the software to the point of self-destruction.
One good example was an [unnamed] JDBC driver that wrote very elegant object oriented code but unfortunately accounted for 90% of the CPU and memory load of neighboring application. The overhead was small but subtle. Each component allocated and threw away objects.. Each such operation required potential garbage collection and initialization. There was never anything more than O(n), but there were several such O(n) calls within a single JDBC method invocation. The k's compounded enormously.
The thing is that you wouldn't really notice the overhead if you only accessed the JDBC once or twice. Unfortunately we happened to utilize jdbc calls in loops, which exposed the innefficiency. By using a different driver (which performed optimizations such as utilizing a static StringBuffer to avoid ANY memory allocations) the JDBC overhead became negligable.
The moral of the story is to identify (at design time) critical loops AND critically accessed sections and consider performance.. This is profiling 101, but I hear more and more java-developers arrogantly transcend such problems.
Untill somebody wants to play a networked video game that only works on Windows.
Others have already said this but the BUS size is irrelevant.. This is obvious when you consider that SDRAM has a 64bit pipelinable bus, and everything from the Pentium on has had 64bit CPU bus's.
Moreover, bus size isn't as important as bus speed.. Otherwise Intel + Rambus wouldn't have created a 16bit memory bus (with frequencies insanely higher then the state-of-the-art at that time).
Moreover, I haven't looked at the details in a while, but I heard that the North/South/East/West bridges of the opteron will only be 16bit (most likely to minimize pin-out hell).
This topic has been battled back and forth. 64bit address size means 2x the code size for memory addresses (AMD acknowledges a 1020% code size increase).. This translates into more wasted cache space. This is worsened by the fact that pre-ops are required to maintain binary compatibility (wierd concept since it's in a new operating mode).
Moreover, it is incorrect to think that you can compute a 64bit number in the exact or (fantastically) in less time than a 32 bit number. Period. Now, clock speed is determined by the slowest possible operation you need to do in a clock-tick.. Thus, this might be the point that you suggest is incomparible. If a 64bit ALU op isn't going to be slower than say a register fetch or a certain stage of the floating point unit, then yes 64bit ALU won't be a bottleneck.. But remember, some parts of the CPU require doing an add as just one part (such as doing a memory fetch/store). This is especially problematic for CISC machines which potentially can do "add MEM1, MEM2, MEM3". HOWEVER, Intel's P4 definately would feel the effect. It double-pumps the integer ALU, so the slack-space is less avail.
The rest I agree with.
Front Side bus mainly applies to memory hog applications (which of course the 64bit issue can applies to this as well).. But when we look at speedups for games such as counter-strike, what we see is that the speedup really comes from adding an extra set of registers.
What the x86 line needs is not more memory, cleaner instruction set, or better memory management, but more registers.
I'm somewhat upset that AMD didn't make it's x86-64 use 32 registers (the defacto standard these days). Morever, given that Intel added a ne w operating mode for use with SSE, I don't see why AMD couldn't have added one that merely provided the 32 registers for x86-32. They would have a HUGE jump on Intel with hardly any additional cost. Most compilers implement algorithms that are register-set-size nuetral, so it should not be a dramatic rewrite for anybody's compiler. Granted, you muck-up most of the op-codes, requiring more bits per register, but that's what the new mode is for.
Going to 64bit, otoh is an enormous change.. Not to mention, I don't believe AMD gives you the option of using the extra register without requiring 8 bytes per pointer (thereby losing the space-efficiency of 32bit coding).
While I'm happy to see any progress, I'm disappointed that the root-canal type changes that will be necessary to support x86-64 aren't going to bring the PC up to even 1990's technology standards.
Minor nit-pick with your analogy.
The speed of sound in a medium is a function of the average velocity of the molecules in that medium. This is based off of the ideal-gas law, utilizing the probability of direction of particles bouncing off one another.. Collision of gas molecules against solidly compacted forces (such as the front-end of an ship (air/boat), an explosion wave-front, etc) merely causes the molecules to divert their direction, and such ping-ponging causes neighboring molecules to divert, thereby causing an effective motion of the gas. When a large body of such molecules move in the same direction (on average), we call this a current.
Wind is such a current, rivers are such a current, electrons propagating along a conductor is such a current. In each of these cases, a single particle (molecule/electron) is not moving the entire length, but the net motion of all the colliding and direction-changing particles is.
Thus, as with the speed of light, for net-aggregate-velocities (current velocity) much much lower than the average velocity of a given particle in the medium, you can use linear superposition. Namely, if you are in a car moving at velocity x, and you through a book forward at velocity y, then until air-resistance slows you down, the book will have velocity x + y.
However, as you approach the average speed of a particle in your medium, the particles on your wave-front can't move forward fast enough to "get out of your way", so the apparent friction becomes non-linear (polynomial, in fact). You are now accelerating the particles in front of you, and apparently gaining mass (as far as propulsion is concerned). BUT, the key is that you are accelerating the particles in front of you.
I believe the formula for friction in an ideal gas is something similar to:
1 - V^2/Vavg^2
Which is related to the lorenz contraction factor.
Ideal gas law does not mean that no particle ever travels faster than the average.. In fact, if enough energy is released into the gas such that it's temperature (e.g. aggregate kinetic energy) rises, the it's average velocity is indeed increased.
Thus my nitpick is that for the analogy where a repulsive force is sound and gravity is wind.. As your "wind" velocity increases, you are, in fact, increasing the average velocity of particles. Any perterbations (shock waves, aka sound), now can propagate faster, though in a non uniform manner (the direction of the wave will be faster in the direction of the wind (parallel direction), average in orthogonal directions and dramatically attenuated in anti-parallel directions).
Further, if the auditory devices (sound-generator, and target) are carried along with the medium, then their relative velocities will be constant with respect to the medium, and sound will effectively probagate uniformly.
There is one tiny wrinkle in all this. Here, the max velocity is consdered to be Vavg and is changable. In quantum physics, Vavg is the speed of light and can never be exceeded (at least on average). Thus linear superposition breaks down. Increasing the velocity of the wind means that particles ricocheting forward can't produce a net propagation velocity twice as fast relative to a stationary transmitter/reciever.
Theoretically, all the quantum "forces" are effectively energy moving through space and time at different ratios. Plotting them together as a 4D space-time plot, the magnitude of the 4D coordinate should always equal c. Thus if you are traveling along the event horizon at c in any one direction, then you should have no remaining ability to travel in any other directions (including time). Thus perterbing the medium should be impossible. The event horizon would be like having a steel shell that is oblivious to outside disturbances (ignoring that steel allows for elastic collisions, including sound). I speculate (as a lay person) that the reasoning that event horizon particles are oblivious to anti-parallel disturbances is because they have
While I acknowledge that the geometry radically alters in the presence of intense gravity (in fact, String theory suggests that the number of dimensions collapses inside a black hole to an effective singularity (though protected by minimum plank-radius)), I'm not comfortable using the phrase circumference to describe it's externally apparent dimensionality.
At the least, you'd have to consider the black hole as a 2D surface (or shell). Which is still related to r^2.
Only speaking as a well read lay person, I've heard black holes being described as 2D planes; all the mass exists within the event-horizon (since time slows down as you approach it, approaching the speed of light).
That being said I can almost comprehend space being warped enough such that the r^2 flatens out to r, but It's still beyond me.
Actually in 7.3 you can finally drop columns, fwiw.
I don't know about MySQL 4, but the biggest problem is that MySQL seemed to emphasise speed over robustness.. Large scale benchmarking in the 3-tree caused corrupted databases. postgres has had a journal for a little bit now (don't know how long though). Plus postgres's version-based rows allows for some really high performance parallel transaction control.
It all comes down to what you are really trying to do.. If you're willing to lose a day's worth of work, and you're not going to have more than a couple dozen simultaneous connections, then MySQL is probably good for you.
Perhaps 4 has allowed MySQL to catch up with Postgres / surpase it, but it's had too murky a history for a lot of businesses who rank data-integrity number 1.
Someone please mark parent up. Very informative
There's always red carpet. Somewhat frustrating for certain configurations, but it works.
As an engineer:
:)
Torque is a measure of the ability to do work. Foot-lbs means how many lbs of Force is applied at a leverage point of 1 foot.. It's the same as force, but in an angular orientation instead of a straight one.
Horse Power is the measure of Torque at a given RPM. Force in a given time is called power; the ability to do work "quickly".
Thus a truck have enormous torque and thus can have a really high horse power at low RPMs (namely lugging tons of material from a complete stop where RPMs are between 600 and 2,000). The problem is that the massive design of their engines do not lend to high rpms, therefore it does not scale.
Moreover, the engine itself has such impeedence that it just physically can't accelerate it's own engine's RPM, much less that of the entire vehicle.. So even if you took a truck engine and installed it in a geo, you wouldn't have a fast accelerator, though you WOULD make the tires spin for the first second.
In this analogy, other's have already said that the truck vers.s the geo analogy is probably more of what you're trying to say (at least with 32 v.s. 64 bits).
The torque v.s. horsepower is better suited to wide v.s. deep. A deep architecture (many parallel execution units) can do a lot of work (though this is independent of how fast it can do it). Deep allows a rapid "ramp-up", and can achieve incredibly high speeds (though it may not actually be getting any more total work done). Put another way, Instructions / clock (torque) and clocks / second (rpm), or Instructions per second (Horse Power).
With high Instructions / second, however, you have to differentiate between peek and sustained. The same is also true with width, but to a lesser degree.
Still, it's a fun analogy.
Since your address word-size changes in 64bit mode, imagine the horrors of having different sizeof(void*) from function to function.
I can't imagine this something you'd ever want to do (what size would malloc return?).
Still, I can see a potential problem. If you have a Linux distribution, some binaries will want to be 32bit, and some will want to be 64bit (what other purpose would there be to having such a compatibility mode). But shared libraries (libc.so) would be really nasty.
I've read here that ELF can support multiple architectures, but you'd still have to compile the darned code twice for each shared library.
Anybody know how this sort of thing is handled?
I know I just gave programming examples but a tool is a tool, and students should be given a wide variety of them so they can make the choice.
.cshrc files and custom macros/scripts.
Furthering the base comment, a higher education degree is meant to teach you theory, not a practical trade. If you want a trade, go to trade school (which includes programming). The rationalle might be that if you feel like you know everything there is to know about something, you will cieze to ask new questions, or consequently make new discoveries.
The theory behind a dependency list is useful. The particular features of a given make-tool is not (in terms of theory). The idea of a GUI is useful, a particular IDE emacs/VS/idea/etc is not.
Moreover, we learn best by discovering on our own; therefore a good university only gives you the building blocks necessary for you to discover after the fact.
I remember our professors specifically using in-house libraries, languages and environments, specifically so that we wouldn't get pigeon-holed into learning how to use a particular brand of tools. We weren't even taught UNIX operations.. We were inundated with class-specific
It was only after a couple years that many of us students could discover the hidden powers of UNIX.. And even then, mostly through our peers. What a great preperation for the real world.. Especially since in the real world, we rarely have a managing professor that knows what the answer eventually needs to be.
Lets see some real binary code reuse in linux, and not this crap where App A needs libfoo1.1.so and App B needs libfoo3.4.so. If I need two different versions of the library for two different apps, guess what, that ain't code reuse.
.avi, .wma. There are plenty of popular tools to generate .png/.jpg/.mpg, and windows actually supports these formats. More-over there are currently no proprietary "extensions". But word-documents are the foundation of the work-place. The fact that MS won in the office wars is not a problem. The fact that the format of office documents is not reliably renderable on peer machines is the problem.
Would you rather App A symply not work because App B's required libfoo3.4.so isn't backwardly compatible? Or would you rather have everything staticly linked?
Heck, half the time, libfoo1.1.so is a symlink to 3.4. I don't understand what your problem is.
I mean sue Microsoft when they break laws. Having a better product isn't anti-competitive. It is competitive, it's just that noone else is competing.
While in principle I agree with you (people should focus energies on outclassing MicroSoft), the reality is very different. The issue that has to be addressed is the barrier to entry.
1'st tier: Make an audio platform that can be used by 3'rd parties.
This would require that each apps that wants to use widget-class-X needs to be able to go fetch / download and install it without bothering the user. Any complications in this process are such that app developers won't want to be bothered or liable for the associated tech support. Thus, if there is a "standard" garunteed installation of widget-class-X, then any sane developer would use the default. Since MS ships many and eventually all widget-classes, the defaults are usually/always MicroSoft apps.
BUT, any such app is really just part of a widget-class. Thus any non MicroSoft producer is likely to not be purchased if there is already a bundled default.
The cycle repeats itself as MS includes more and more default widgets.. Now you may think this trivial for something like media.. Maybe you even think it's trivial for a web browser... How about a web server? How about a file-system diagnostics? So on and so forth.
Now you could argue that these attributes are part of the Operating Environment (OS is a tainted word). This is merely the platform for the "real" user applications. Like video games, office products, money/resource managers, etc.
But the next issue is application interaction. Media is regularly communicated between different PC's.. Via email/sneaker-net/etc. The format of that media MUST be compatible.. Thus either you need an application that can render the media or you need to own the same software-vendor's media-package.
By media, I'm actually speaking of word-processing, spread-sheets, presentors more than jpg,
The reason MS is the champion of office apps is because they killed off their competition, and they've managed to get people to regularly upgrade to the latest version.
They way they do this is through lack of backward compatibility... If userX upgrades office; they'll generate documents that are not renderable by other peer users. Thus what often happens is that other users are greatly encouraged to upgrade as well.
Likewise, competing WordPerfect or what-have-you is generally incompatible and thus TCO is reduced if only a single vendor is consolidated to..
Thus their monopoly developed out of a cripling of one of the points of an application; interfacability (being interfacing with the user or other apps).
To be fair, it is unlikely that they went too far out of their way to hold a proprietary format.. It is more the fact that they didn't abstract the document format from the rendering process. (Embedded links to applications). I'm sure they made a contious design decision to lock customers in, however.
The problem is that once a person is has something that is adaquate, they will be unwilling to replace it was something completely new.
The end result then becomes an unregulatable monopoly. This monopoly allows them to basically tax every computer-bering man-woman-and-company on the face of the planet.. That in turn gives them enough resources to hire large numbers of "talented" people. Which in turn allows them to more quickly write widget-classes to encroach into ever newer markets, persisting the cycle.
The problems for the end user are that we're basically semi-willing citizens of an software dictator.. If they charge more money, we're forced to pay (their military is the BSA). If they break compatibility and successfully promote a version upgrade in one segment of the world, eventually everybody must upgrade to follow sute; and thereby pay their MS-tax. If they want to police you (as in 1984) then they are fully capable: (media player CD-title taddle-taleing, Win-Update installed-software taddle-taleing, and lord knows what-else).
Our lives within the computer are litterly based on the whims of MS. The only thing that prevents them for doing more to subvert us and charge more from us are practicality measures.. Suppy and demand limits their fees (but they grow as much as as fast as they can), policy viability (Their hailstorm failed in it's first attempt).
MS MUST be checked somehow, and it is unlikely to be viable through competition. Even if we wanted to, we could not all migrate to Mac's (the next most practical alternative). The application base just isn't there.
These words make me cringe like you cannot believe.
I know and I appologize for bringing it up.. But since I've already gotten you to this level of interaction. I'll press my luck.
Surely there is no end to the interpretation of the writings of Nostradamus...they happen to be confusing and oblique from almost any perspective.
Agreed, I was referring to both "prophetic" works.
However, if you again are referring to the book of Revelation, there is very little that is up for "interpretation."
Wow, this was the kicker that made me want to reply. I've never actually met someone that felt this way.
In fact, I recall going through a very interesting "interpretation" which suggested that the entirety of Revelation was meant for the times and life of John and Christianity's great tribulation: Nero Caesar.
Not speaking greek, I can't attest to the "clearity" of which you speak, however I have gone through books that had greek on left, english on right, and was not as convinced as you.
As for the rest, I'll merely say that I have a problem with the phrase "undisputed" in relation to anything biblical. To attest to the correctness of a work is one thing, but to suggest that no-one has presented serious and succesful logical opposition is straining credibility. A work that makes an untestible claim is not free of scrutiny. It is no more "correct" than fiction.
Generally the entire period is considered to be more than a few days, and contain more than a few tragedies. Exact timing, however, is somewhat of a farse. There are references to thousands of days and thousands of years being interchanged. You'd be hard press to interpret the timing literally (7 days of creation anyone? Or how about the Jehovah's Witnesses?)
That being said, I was actually more focusing on interpretations I'd read on Nostradamus.. It's been a while since I'd studied revelations.
I'm almost sorry I brought it up though, because this is a matter of faith (or lack thereof) and there's no end to such interpretation.
In a war people are violent, often long after the war. But that's more than just the collapse of society, that's an extension of society's self-destruction. Few apocolyptic scenarios involve mass societal collapse as a cause..
Step 1) Shock/Fear: Mass fear (will might die, my family might die, where will I live?, what will I eat?).
Step 2) Hysteria: People vauling their families or in worst cases, themselves over anything, including common human decency (trampling over people, driving over people, etc). At this stage, we become primally instinctive; we're in self-defense mode.. We're not able to think rationally.
Step 3) Anarchy: Hysteria slowly calms down.. We're no longer screaming (though many are still crying). Depression will start kicking in for some.. Many will lose hope. Many will start to think about the future. They'll quickly rationalize lawless activities. Rape, looting, general acts of violence.. People will chant the "end of the world", and try and live out their fantacies.
Step 4) Pragmatism: As the remaining loyalist military/police kills off the most violent offenders, the more remaining people are in three camps.
a) The "victims" that will not be able to recover on their own; they will need to be followers.
b) The "leaders", these will be people that will try and help out; working through the wake of disaster. These will be the optimisits. Being somewhat altruistic, they will fight for what they consider right, even in the face of dispair.
c) The selfish. These are people who will quickly surmise that it will take decades (if ever) to recover, and in the mean time, we will be living in the stone age. There will not be enough resources to sustain the remaining levels of population. Fresh water will be virtually non-existant due to polluting drainage, and lack of pump-work. Rain-water is likely to be hazardous, and possibly droubting. Thus the selfish will realize that if they forcibly coerse other's, the "leaders" (including the military) will have them killed. Thus they will subtly backstab, usurping power (at least within their community).
The problem is that only those smart enough to survive will become leaders. But as a follower, you can't be sure that your local leaders aren't secretly maliscious.
The fact of the matter is that people will die due to shortages, and in the face of this, the majority of people will act accordingly, even in the long run.
This will continue until either the population has dwindled to a sufficiently small group (which is unlikely given the then-newly-encouraged birthrate), or complex and corrupt power-systems will develop, which can contain the selfish class. Tyranical Dictatorships are the only systems that can contain anarchy. It is only given enough time and prosperity that benevolant systems can prevail.
In short, we're talking hundreds if not thousands of years to rebuild society.
If you're into apacolyptic tales, Revelation and Various profits (Nostradamus, etc) tend to talk about an apocalyptic aftermath which takes hundreds or thousands of years. So in short, I disagree that a cataclysmic event would have to be radio-enduced.
Sorry, but tablet PC's, notebooks and especially PC's don't match the readibility of the printed page. At least not yet.
The printed page allows you to cheaply have a group meeting where individuals make annotations, read-ahead / reread-behind independently of the presentation. An electronic device per person assumes interconnectivity (real issue when you're dealing with 3rd parties), and availability. (Company-wide meetings don't do well for providing every intern a laptop).
Also, I've yet to see a pen-style aparatus that's as easy to use as pen+paper. Putting your brain down on paper requires artistic freedom that the rigid uniformity of typed-text or even paintbrush-style apps can't yet provide.
If you're at school, it's unlikely that all your classes will allow e-submissions of your works. Especially if they're handing out form/exams for which to fill out.
If you're trying to comunicate with older relatives that boycott computers (yes there are still many alive and kicking), it's an absolute necessity.
Paper is still an order of magnitude more compact than a laptop (which generally desires tons of accessories). Personally, I still boycott laptops. The only requirement is to make sure that every place that you frequent have net access.
The paperless office was a pipe-dream - As the saying goes - If anything, computers have grown the requirements for paper many fold.
This isn't to say we shouldn't strive for it. Just that the lexmark issue is very real; especially given the clientelle of lexmark (budget minded home users and students).
I agree with you somewhat, BUT your argument is not very good.
if companies like Lexmark are allowed to decide what manufacturers are allowed to sell supplies for thier printers what is to stop car manufacturers from forcing car buyers to purchase specific types of gasoline or oil?
and
What's the next step? Only being allowed to you Lexmark approved paper in your printer?
The issue is that gas and paper are not under the controlling interests of auto manufacturers nor printer manufacturers.
The specific inkjet nossel, or toner cartrage is highly customized to fit the particular printer. Thus it's entirely possible to use the DMCA to conceal the API, or the patent the particular usage of the device. Someone that makes paper can do so for any number of printers; and thus can't have an injunction. Someone that goes out of their way to produce a cartraige that fits a particular printer has an obvious intent, and thus is at least susceptable to court harrasment.
What Lexmark and friends do is put 90% of their technology into their print-head. This makes the design slightly more expensive but it garuntees that you can't take advantage of alternative vendors.
Actually, if you read the article, PCI and ISA can still be supported. ISA is supported on current PCI boards through a host-to-host-bridge. Likewise, the new architecture can support PCI, and there's no reason to think ISA couldn't be supported.
The issue is that such a bridge costs money and space. The majority of people purchasing new computers (with no intent on upgrading HW) will want the cheapest, most-compact solution. This is the problem that faces video card retailers. They'll ahve to carry two lines of video cards (3 if they seriously still sell PCI versions), and they'll have to conflict amongst themselves as they market different HW. Especially in the months leading up to the roll out.
No word on whether AMD boards have any chance of supporting the new BUS. If not, then AGP cards will persist for some time.
That's a perversion of the words dynamicly-typed. ClassCastException is similar to c's dynamic-linking errors.
Perl/Scripting languages are dynamically typed, not because they can load modules at run time (which just about every language I've ever heard of can), but because they auto-declare variables, because you can create/modify code at run time as part of the native language. The symbol table of perl is nothing more than a modifyable hash-table (except for lexically typed variables (my $foo)). This includes variables, functions, "magic" symbols, etc.
Yes, Java does have reflections, which allow completly dynamic interaction, BUT, would you write any substantial fraction of a program using this? This was an exception to the original java-rule-set, which allowed for greater total flexibility, but I would be hard-pressed to call Java Dynamic because of it.