Right click My Computers > Properties > Hardware > Device Manager:
That's Windows you're working with. And if you are using Windows in an industrial environment, you've already screwed up. Forget about the usual/. nonsens of Windows Bad, Linux Good. Actually, you'll need a special RT version of Linux. According to Microsoft licensing terms Windows is NOT suitable for use where life or property loss may result from failure. Game over.
If you only need POSIX C, then there are even better options, such as VXworks and QNX. If real-time response and availability matters, then a modular microkernel based operating system is the way to go.
For example, take a look at Cisco's IOS XR, which is QNX based. It can even restart crashed drivers, which would take both Linux and Windows down in most circumstances.
Just because you have a hammer that's not as blunt as another hammer doesn't mean you should use it as a chisel!
Conspiracy theories and scientific hypes aside, is man actually capable of changing the properties of something as huge as planet Earth?
Or, in other words, can we stop this even if we want to? Earth will continue changing as it will continue rotating, and we might as well take our minds off what we cannot change and work a little bit more on what we can, i.e. the misery of mankind.
You say that like you're thinking of "one man" affecting an entire planet.
Think of it this way, the surface area of the planet is 5.1x10E8 km^2, but there are 6.75 billion people alive today.
The real question is, can "one man" have an impact on their own personal share of 0.07556 km^2? That's only 7.6 hectares per person, of which only 2.2 hectares is 'land', which includes mountains, desert, and ice. This leaves about 1 hectare of productive land for each human being.
So the better question to ask is:
Are men capable of changing the properties of something as huge as 1 hectare each?
Doesn't work for me on Vista 64 Business. Alt + Enter in a command window does nothing.
That's a 32-bit "cmd.exe" window, the grandparent was talking about the 16-bit "command.com" style windows that only exist in 32-bit installations of Windows, because they are actually 16-bit code running in a virtual DOS machine called "ntvdm".
I want nuclear fusion that can fit in my pocket. That, combined with my Quasimodo-esque looks, will almost certainly guarantee that I never reproduce (which could only result further degradation of the planet's gene pool);-)
You can get nuclear fission that'll fit in your pocket now, and safely generate electricity.
All of those can be miniaturised, and use a radiation source that only emits beta particles, which won't penetrate through the case, so you won't have to sacrifice your looks for convenience.
Which says nothing about the power stored without the voltage across the planes!
W = C V^2 / 2
The energy stored goes as the square of the voltage. It drops precipitously as the voltage approaches 0, as it does in this case.
Even if you somehow managed to get 100mV of potential difference*, that's still only 800 mJ of stored energy, or about 2kJ/kg specific energy. Compare that to just burning the graphite at 32.8 MJ/kg (not counting the weight of the oxygen), which is about 16,000x greater!
You'll find that the energy stored in the internal stress of concrete is similarly low. Chemical energy density is surprisingly high, only nuclear power sources beat it.
Try it, look up the typical stress in a block of pre-tensioned concrete, and work out the J/kg and J/$!
*) Not likely! At that charge, the electric field strength between the layers is 700MV/m, which next to nothing can resist. See: Field Strength computation. Air breaks down far below that, so the stack would short out towards the sides where it is exposed, at the very least.
PS: All of these computations may be off by a few orders of magnitude, it's nearly 1:30 in the morning here...
Except that if the alternating layers have opposite charges, those charges set up an electric field, which will pull electrons from one side to another, and the charges cancel. There doesn't need to be a "connection", the electrons will cross the space between the layers anyway.
If you place an insulator between the layers, then you've just invented a garden variety capacitor, but the problem remains: with sufficient charge, the electric field between the layers will exceed the breakdown voltage of the insulator, which will then conduct and short out the layers.
The breakdown voltage is closely related to, you guessed it, the chemical bond strength of the insulator. It's not a coincidence that the best insulators tend to be strongly bonded covalent substances like ceramics and oxides.
We've just about hit the wall on insulators, most capacitor development has been about making the conductive layers thinner. Only the outermost layers of conductive atoms store the charge, everything else is just redundant, so getting rid of as much conductor as possible gives better capacity per unit volume.
The concrete example is no good either. It's much the same scenario as the compressed matter in the article. In the case of reinforced concrete, the steel is providing compression, but you'll find that the total energy stored is not very high per unit mass of steel. If you try to increase the energy stored with greater tension in the steel, it'll break at some point, which is determined by... the chemical bond strength of the metal.
I used to study batteries and capacitors and the like in relation to energy storage, and one interesting comment I heard once was that storage utilising only chemical or electromagnetic methods cannot store more energy in a given lump of matter than the energy contained in its chemical bonds, otherwise the stored energy exceeds the "binding strength" of the substance, and it's liable to either leak the energy, not accept any more, or even explode.
This is true of even things like Ultracapacitors or flywheel storage, both of which have similar issues with breakdown largely caused by limited bond strength, despite neither using chemical energy storage.
This kind of "high pressure storage" seems to break this rule if you consider only the compressed material itself as the storage medium. If you factor in the anvil generating those pressures, then you'll find that the total system is probably quite bad at energy storage per kg of matter. There's no escaping this.
The pressure they were using is over 100GPa (1 million atmospheres), which is notably higher than the highest tensile strength of carbon nanotubes ever measured! There's no chance in hell that a practical container could be made to contain a material at those pressures. First of all, it would have to be atomically perfect, and second, it would violently explode if it received the slightest damage!
What the article was saying is that some of the energy imparted by the compression was stored as chemical energy. This is all fine and good, but I guarantee that if the pressure is lowered, that energy is released, and none of it can be stored at normal pressures.
Trust a dumbass journalist to rewrite that to mean that suddenly our electric cars will be powered by Xenon Fluoride compressed by diamond anvils, even though the original research paper doesn't mention anything of the sort!
No, they just designed.NET to always execute fully compiled. Unlike Java,.NETs "intermediate code" was never intended to be interpreted at runtime. Instead.NET JITs an assembly (dll) before executing..NET even supports creating assemblies dynamically (no hacks) through Reflection.Emit (no need to save to files and do bytecode manipulation). A dynamic assembly is still compiled fully to machine instructions before execution begins.
I was just reading the.NET 4 help file on this this week, and the JIT compiler is invoked on a per-method basis. The virtual function table is used to substitute the compiled methods for the original bytecode.
One difference between.NET and Java is that.NET invokes the JIT on the "first call", whereas Java still prefers to run code using emulation until a method has been called a certain number of times, after which the JIT is invoked. You're almost right:.NET never executes anything other than compiled code, but the compilation is done in smaller increments than a whole DLL!
The program installer has to explicitly invoke 'ngen.exe' to trigger a full compilation. Lots of programs do this. You can tell because the installer takes forever to run even with fast drives (e.g.: SSDs), and the CPU sits at 100% for a long time...
The solution to that is just having a minimal story, like NetHack does. You simply have a story outline and you're free to make up more parts yourself through conducts or similar things.
OMG... I just realised I hadn't ascended in months.
Sorry, but I'm a mathematician... so everything you physicists do is just a model to me.
An instant link to xkcd is required here. I hate doing this (linking to xkcd), but you brought it on yourself:)
Haha... exactly! The more we learn about physics, the more 'pure' our models will get, and the closer we get to stand to those elitist mathematicians. 8)
It's already widely known that Relativity is just a model... much like the rest of physics. It's extremely accurate and useful for dealing with many areas, but breaks down somewhat when dealing with very very small things. Hence the great desire to develop a more unified theory! So, the summary is a little bit on the sensationalist side of the street.
The research is very important, though!
That's a gross misunderstanding of the problems of relativity.
"Just a model" is not what physicists seek. The aim is to seek laws of physics that are absolute, inviolable, and a complete description of space, time, and mass-energy. Some of our models are basically there, like the "conservation" laws, which are based on rigorous mathematics.
The problem with relativity isn't that it's "just a model", it's that it is explicitly known to be incomplete. It simply doesn't "extend" down to small scales. This was known by Einstein himself, he sought to complete his theory, but failed.
SSDs are going to hit 6 gbit/sec in the next year or so. Multiply by 17 devices on a SAN and you're done.
Those are consumer grade devices. Many SSDs are already well above 10Gbit speeds, and I fully expect 20Gbit in a single PCI-e card this year or early next year. Just 5 of those could saturate 100Gbit!
It's interesting how this will increase the adoption of iSCSI storage, yet the original reason to go to iSCSI will be lost since fiber cables will have to be laid.
That seems a tad disingenuous. The real reason for iSCSI was a Microsoft price structure that made a network file service very expensive unless it went in through the 'disk-on-SCSI-bus' back door.
Linux and iSCSI was a way around the high cost of a MS server/client system. None of the Linux-only or Macintosh network systems were so encumbered, and worked quite well without any iSCSI.
WTF are you talking about? Why was this modded up? Is it just because he's saying something negative about Microsoft?
I've worked in Microsoft Windows server environments for a decade, and I've never heard of SCSI specific MS licensing, or any kind of special licensing at all for file servers.
While it's true that a Linux server in general is cheaper from a licensing standpoint (hard to compete with free), that has nothing to do with iSCSI, SCSI, or FC.
The reason iSCSI is popular is because it's simpler to set up, halves the number of ports and switches required for a fully redundant server environment (minimum 2 ports and 2 switches vs 4 and 4), it has real authentication instead of the worthless "zones" crap in the FC world, provides user friendly names instead of numeric IDs, has encryption, 10Gb Ethernet can outperform even 8Gb FC, and even old 1GbE switches can perform adequately if port trunking is used properly.
What this all boils down to is that iSCSI is both better and cheaper than FC. Once popular SAN arrays from big vendors start to appear with 10GbE iSCSI as standard instead of an expensive "option", then FC will start to die a rapid and well deserved death.
Except that the trend for years now has been towards file formats that are already compressed.
All of the Office 2007 and later file formats are just zip files full of content. Try it, rename a '.docx' file to '.zip' and open it! Even Office 2003 can open these with a free plugin.
The OpenOffice ODF format is a zip file.
The Microsoft XPS format is a zip file.
Adobe PDF has had internal compression for a while.
Practically all image, audio, and video formats have been highly compressed for decades.
What kind of stone age file formats are in use at your corporation that additional compression is a huge benefit?
In my experience, the easiest way to get a consistent and stable printing experience is by generating PDF. I have yet to have stability problems if this is done properly. As you're working with Ruby on Rails, using Prawn and Prawnto might be useful. However, if you absolutely positively must NOT use PDF for printing, then this probably won't help you.
I've just recently come across a similar problem. I had to emulate an old-school line printer for an application, with very precisely defined printing, a very specific font with DOS line drawing characters in it that had to line up, etc...
I found that by far the easiest method was to use Microsoft XPS. Generating it is a breeze, and it gives good control over layout. The client application is relatively light weight, which is a pleasant change. It's also trivial to embed an XPS reader into a client-side application, but it's hard with PDF. The client is written in a managed language, so it's got way fewer security holes than Adobe Acrobat, which is like swiss cheese in comparison.
The real problem is time. Even if you could check one move per Planck time (the shortest possible time interval, ca. 5*10^-44s), you'd still need about 5*10^79 seconds, or about 1.5*10^72 years. For comparison, the universe is about 1.5*10^9 years old.
You're forgetting that speed and parallelism aren't mutually exclusive!
If you could somehow convert all of the matter in the universe into a massively parallel computer running at that speed, with each CPU having a budget of ~40 million particles, then you'd have a computer that could play chess perfectly, providing each move in about 24 hours at first, and then probably speeding up a bit as the game progresses and there's less of the state space to check.
Your homework for tonight is to build two such computers using different methods, and compare the relative merits of each solution. Show your work.
Reminds me of a classic database developer nightmare story that I heard:
A local school was receiving complaints that two students were getting the exam results and the like mixed up.
The two students? Identical twins living in the same house, with the same name.. John Smith Jnr.
Apparently their father was John Smith Snr, and the whole "Senior / Junior" thing has been done for generations of "Johns Smiths", and it was a tradition and all, and we can't just break a tradition just because we had twin boys.. so... we'll name them both John Smith Jnr.
I did the same test a couple of years ago. I was writing an app for a huge data set, but I was told to do the proof-of-concept on both Oracle and SQL Server. I used two identical servers, identical SAN volumes, etc...
The result was shocking. Oracle is at least 5x as slow as SQL Server. It seems to pick acceptable query plans, but for some reason it's just... slower.
One possible explanation that occurred to me is that SQL Server clusters all data by default, whereas that's an optional 'feature' in Oracle. If you try to cluster data in Oracle, it can break other functionality, so it's not the default and developers can't always just turn it on.
Inserting bulk text seems to be awfully slow for some reason as well, and I couldn't figure it out. I saw forum posts along the lines of "well of course it's slow, you're working with text". Meanwhile, SQL Server was doing the exact same thing 50x faster.
Now I don't wonder any more why the Oracle EULA prohibits benchmarking.
Try googling for "Oracle Benchmark". You'll be lucky to find 2 or 3 on the entire internet that compare it to something else, and weren't done by Oracle themselves.
a) Electricity is only a small fraction of the total power used by a country. Think fertilisers, transport, and industrial energy, much of which is still oil or coal based even in countries where electricity is generated using nuclear or hydro power.
b) New Zealand is a very mountainous country with a low population density relative to the natural resources available, allowing much of their energy needs to be met using hydro. This just doesn't apply to most other countries. Here in Australia, we have a lot of hydro an wind based power as well, but it just doesn't add up to a large percentage. A lot of our power still comes from coal and oil.
This is like saying "we're lucky, maybe you should be luckier also, that'll solve your problems!"
Absolutely not! Snapshots are perfectly safe for capturing your database data.
On real server operating systems snapshot support is integrated into applications, which receive a "snapshot about to occur event" so they can quiesce their writes for a short period to make the snapshot clean.
For example, on a Windows server, a VSS snapshot is a complete restorable backup of everything, including your databases, event logs, the registry, etc... It's the standard mechanism that practically all Windows backup tools use. They take a snapshot, back it up, and then release it. The point in time that the snapshot was taken turns up in the "last backed up on" date field in SQL Server!
Even third party snapshot mechanisms integrate using plugins. If you take a snapshot with, say, VMware or your SAN, then the same quiescing mechanism is triggered.
Some real server operating systems like HP-UX appear to have LVM extensions that are similar to what VSS can do, but I can't find the equivalent in Linux. From what I can see, the closest you can get is to temporarily halt writes from the ext3 filesystem, but that's not the same thing as proper application quiescing.
someone with absolutely no experience with enterprise-level businesses
It's actually worse than that. People that should know are surprised:
Staples says companies have found alternate uses for tape, such as for nearline and offline storage.
Apparently it's news to Staple that companies began using table for offline storage about 60 years ago.
You get 1.5TB (3TB compressed) of LTO storage for about $120 in quantity. You stuff a pile of those in a library, configure the backup schedule and go home. The library tells you when to cycle out the tapes. It works really well and all the hardware and software costs less than what the guy who operates it gets paid in a quarter. Volume snapshots solved the last actual problems that this process ever had.
I just did a price comparison. According to a quick online price search, I can get an LTO 5 cartridge for about AUD 155 to AUD 200, but I can buy a Samsung 1.5TB hard drive delivered to my door for AUD 138!
A standalone LTO 5 tape drive has a minimum cost of $thousands, and even a low-cost autoloader is $thousands more.
For any small business with less than 1.5TB of compressed data (2-4TB actual data), tapes are dead.
And don't tell me that tapes are somehow more reliable than hard drives, because they're not. A hard drive comes with it's own sealed steel box, and a tape will die just the same if you drop it onto a concrete floor.
What's much more important is that restoring to bare metal is much easier with a USB hard drive, particularly with Windows Server 2008 or later. The VHD backup images can be restored using the standard Windows installer CD. Because USB3 is backwards compatible with USB2 a restore can be done without any special drivers or software.
You know what isn't fun? Chasing down drivers for tape libraries at 3am.
Meanwhile, large corporations are moving to hard drives for different reasons. A chassis that can take ~48 SATA drives is now only 4 to 5 rack units. Even fully populated with 2TB drives it can end up cheaper than an empty tape library of the same capacity. Hard drives are much faster, allowing them to be used in more ways, such as single-instancing and simultaneous backups and restores. Many organisations now do incremental backups every couple of minutes to disk, which would be prohibitively difficult with tapes.
With single-instanced backups, the cost per TB swings towards hard drives in a big way. I've heard of 50:1 compression ratios in practice, and 250:1 is not outlandish. You'd have to buy LTO 5 media for a dollar each to match that!
All of the gains we make in hardware are eaten up as fast or faster than they are produced by two main consumers: useless eye-candy for end users, and higher and higher-level programming languages and tools that make it possible for developers to build increasingly inefficient and resource-hungry applications faster than before. And yes, I realize that there are irresistible market forces at work here, but that only applies to commercial software; for the FOSS world, it's a tremendous lost opportunity that appears to have been driven by little more than a desire to emulate corporate software development, which many FOSS developers admire for reasons known only to them and God.
This is a common misconception in the computing world: that somehow the additional computing power is 'wasted' on 'bloat'.
The basic principle that one has to understand is that in the meantime, human beings haven't changed. Our brains haven't improved in speed. There is no benefit to us if a program responds in 1 microsecond instead of 1 millisecond.
However, in terms of 'features', programs are still far behind where they should be. There's an awful lot that we as programmers could do that we aren't, either because it's too hard, or because the CPUs just couldn't handle it. Things like predictive text input, grammar checking, mixed languages in a single document, precise font-rendering, etc... make even simple applications like "word processors" very complex internally. All of this complexity makes it difficult to program in low-level languages, so programmers are moving towards easier to use high-level languages like Java and C#. This makes it easier to implement advanced features, at the cost of some performance.
In other words, programmers target a "constant" speed level determined by the properties of the human brain, while the computer hardware changes. This is a lot like the "time budget per frame" that game developers talk about. They target 60fps or 30fps for their games, giving a constant 16.6ms or 33.3ms to do all the required computations in for each frame. Year after year, in that amount of given wall-clock time, processors and video cards have been able to do more, so programmers take advantage of that added capability. There's no point in making a game run at 10,000fps, because humans can't perceive that!
Ordinary office and productivity applications are exactly the same. They target a certain level of responsiveness too, but the processors haven been getting faster, allowing programmers to do more in that time.
Slashdot Mirror
Right click My Computers > Properties > Hardware > Device Manager:
That's Windows you're working with. And if you are using Windows in an industrial environment, you've already screwed up. Forget about the usual /. nonsens of Windows Bad, Linux Good. Actually, you'll need a special RT version of Linux. According to Microsoft licensing terms Windows is NOT suitable for use where life or property loss may result from failure. Game over.
If you only need POSIX C, then there are even better options, such as VXworks and QNX. If real-time response and availability matters, then a modular microkernel based operating system is the way to go.
For example, take a look at Cisco's IOS XR, which is QNX based. It can even restart crashed drivers, which would take both Linux and Windows down in most circumstances.
Just because you have a hammer that's not as blunt as another hammer doesn't mean you should use it as a chisel!
Conspiracy theories and scientific hypes aside, is man actually capable of changing the properties of something as huge as planet Earth?
Or, in other words, can we stop this even if we want to? Earth will continue changing as it will continue rotating, and we might as well take our minds off what we cannot change and work a little bit more on what we can, i.e. the misery of mankind.
You say that like you're thinking of "one man" affecting an entire planet.
Think of it this way, the surface area of the planet is 5.1x10E8 km^2, but there are 6.75 billion people alive today.
The real question is, can "one man" have an impact on their own personal share of 0.07556 km^2? That's only 7.6 hectares per person, of which only 2.2 hectares is 'land', which includes mountains, desert, and ice. This leaves about 1 hectare of productive land for each human being.
So the better question to ask is:
Are men capable of changing the properties of something as huge as 1 hectare each?
I'd say: YES
Doesn't work for me on Vista 64 Business. Alt + Enter in a command window does nothing.
That's a 32-bit "cmd.exe" window, the grandparent was talking about the 16-bit "command.com" style windows that only exist in 32-bit installations of Windows, because they are actually 16-bit code running in a virtual DOS machine called "ntvdm".
I want nuclear fusion that can fit in my pocket. That, combined with my Quasimodo-esque looks, will almost certainly guarantee that I never reproduce (which could only result further degradation of the planet's gene pool) ;-)
You can get nuclear fission that'll fit in your pocket now, and safely generate electricity.
Look up betavoltaics and the related optoelectric nuclear batteries. You can also get lights that'll last for about a decade.
All of those can be miniaturised, and use a radiation source that only emits beta particles, which won't penetrate through the case, so you won't have to sacrifice your looks for convenience.
Isn't science awesome?
This results in roughly 80 farads.
Which says nothing about the power stored without the voltage across the planes!
W = C V^2 / 2
The energy stored goes as the square of the voltage. It drops precipitously as the voltage approaches 0, as it does in this case.
Even if you somehow managed to get 100mV of potential difference*, that's still only 800 mJ of stored energy, or about 2kJ/kg specific energy. Compare that to just burning the graphite at 32.8 MJ/kg (not counting the weight of the oxygen), which is about 16,000x greater!
See: Specific energy computation
You'll find that the energy stored in the internal stress of concrete is similarly low. Chemical energy density is surprisingly high, only nuclear power sources beat it.
Try it, look up the typical stress in a block of pre-tensioned concrete, and work out the J/kg and J/$!
*) Not likely! At that charge, the electric field strength between the layers is 700MV/m, which next to nothing can resist. See: Field Strength computation. Air breaks down far below that, so the stack would short out towards the sides where it is exposed, at the very least.
PS: All of these computations may be off by a few orders of magnitude, it's nearly 1:30 in the morning here...
XeF2 produces _atomic_ fluorine during decomposition. Just thinking about it makes me shiver.
The best thing is that Xenon is a general anaesthetic, and Fluorine is a local anaesthetic.
That's a great combo for consumer gear!
You won't even feel it when you die!
Except that if the alternating layers have opposite charges, those charges set up an electric field, which will pull electrons from one side to another, and the charges cancel. There doesn't need to be a "connection", the electrons will cross the space between the layers anyway.
If you place an insulator between the layers, then you've just invented a garden variety capacitor, but the problem remains: with sufficient charge, the electric field between the layers will exceed the breakdown voltage of the insulator, which will then conduct and short out the layers.
The breakdown voltage is closely related to, you guessed it, the chemical bond strength of the insulator. It's not a coincidence that the best insulators tend to be strongly bonded covalent substances like ceramics and oxides.
We've just about hit the wall on insulators, most capacitor development has been about making the conductive layers thinner. Only the outermost layers of conductive atoms store the charge, everything else is just redundant, so getting rid of as much conductor as possible gives better capacity per unit volume.
The concrete example is no good either. It's much the same scenario as the compressed matter in the article. In the case of reinforced concrete, the steel is providing compression, but you'll find that the total energy stored is not very high per unit mass of steel. If you try to increase the energy stored with greater tension in the steel, it'll break at some point, which is determined by... the chemical bond strength of the metal.
I used to study batteries and capacitors and the like in relation to energy storage, and one interesting comment I heard once was that storage utilising only chemical or electromagnetic methods cannot store more energy in a given lump of matter than the energy contained in its chemical bonds, otherwise the stored energy exceeds the "binding strength" of the substance, and it's liable to either leak the energy, not accept any more, or even explode.
This is true of even things like Ultracapacitors or flywheel storage, both of which have similar issues with breakdown largely caused by limited bond strength, despite neither using chemical energy storage.
This kind of "high pressure storage" seems to break this rule if you consider only the compressed material itself as the storage medium. If you factor in the anvil generating those pressures, then you'll find that the total system is probably quite bad at energy storage per kg of matter. There's no escaping this.
The pressure they were using is over 100GPa (1 million atmospheres), which is notably higher than the highest tensile strength of carbon nanotubes ever measured! There's no chance in hell that a practical container could be made to contain a material at those pressures. First of all, it would have to be atomically perfect, and second, it would violently explode if it received the slightest damage!
What the article was saying is that some of the energy imparted by the compression was stored as chemical energy. This is all fine and good, but I guarantee that if the pressure is lowered, that energy is released, and none of it can be stored at normal pressures.
Trust a dumbass journalist to rewrite that to mean that suddenly our electric cars will be powered by Xenon Fluoride compressed by diamond anvils, even though the original research paper doesn't mention anything of the sort!
No, they just designed .NET to always execute fully compiled. Unlike Java, .NETs "intermediate code" was never intended to be interpreted at runtime. Instead .NET JITs an assembly (dll) before executing. .NET even supports creating assemblies dynamically (no hacks) through Reflection.Emit (no need to save to files and do bytecode manipulation). A dynamic assembly is still compiled fully to machine instructions before execution begins.
I was just reading the .NET 4 help file on this this week, and the JIT compiler is invoked on a per-method basis. The virtual function table is used to substitute the compiled methods for the original bytecode.
One difference between .NET and Java is that .NET invokes the JIT on the "first call", whereas Java still prefers to run code using emulation until a method has been called a certain number of times, after which the JIT is invoked. You're almost right: .NET never executes anything other than compiled code, but the compilation is done in smaller increments than a whole DLL!
The program installer has to explicitly invoke 'ngen.exe' to trigger a full compilation. Lots of programs do this. You can tell because the installer takes forever to run even with fast drives (e.g.: SSDs), and the CPU sits at 100% for a long time...
The solution to that is just having a minimal story, like NetHack does. You simply have a story outline and you're free to make up more parts yourself through conducts or similar things.
OMG... I just realised I hadn't ascended in months.
I knew I was missing something.
Thanks for reminding me!
An instant link to xkcd is required here. I hate doing this (linking to xkcd), but you brought it on yourself :)
Haha... exactly! The more we learn about physics, the more 'pure' our models will get, and the closer we get to stand to those elitist mathematicians. 8)
It's already widely known that Relativity is just a model... much like the rest of physics. It's extremely accurate and useful for dealing with many areas, but breaks down somewhat when dealing with very very small things. Hence the great desire to develop a more unified theory! So, the summary is a little bit on the sensationalist side of the street.
The research is very important, though!
That's a gross misunderstanding of the problems of relativity.
"Just a model" is not what physicists seek. The aim is to seek laws of physics that are absolute, inviolable, and a complete description of space, time, and mass-energy. Some of our models are basically there, like the "conservation" laws, which are based on rigorous mathematics.
The problem with relativity isn't that it's "just a model", it's that it is explicitly known to be incomplete. It simply doesn't "extend" down to small scales. This was known by Einstein himself, he sought to complete his theory, but failed.
SSDs are going to hit 6 gbit/sec in the next year or so. Multiply by 17 devices on a SAN and you're done.
Those are consumer grade devices. Many SSDs are already well above 10Gbit speeds, and I fully expect 20Gbit in a single PCI-e card this year or early next year. Just 5 of those could saturate 100Gbit!
It's interesting how this will increase the adoption of iSCSI storage, yet the original reason to go to iSCSI will be lost since fiber cables will have to be laid.
That seems a tad disingenuous. The real reason for iSCSI was a
Microsoft price structure that made a network file service very
expensive unless it went in through the 'disk-on-SCSI-bus'
back door.
Linux and iSCSI was a way around the high cost of
a MS server/client system. None of the Linux-only or Macintosh
network systems were so encumbered, and worked
quite well without any iSCSI.
WTF are you talking about? Why was this modded up? Is it just because he's saying something negative about Microsoft?
I've worked in Microsoft Windows server environments for a decade, and I've never heard of SCSI specific MS licensing, or any kind of special licensing at all for file servers.
While it's true that a Linux server in general is cheaper from a licensing standpoint (hard to compete with free), that has nothing to do with iSCSI, SCSI, or FC.
The reason iSCSI is popular is because it's simpler to set up, halves the number of ports and switches required for a fully redundant server environment (minimum 2 ports and 2 switches vs 4 and 4), it has real authentication instead of the worthless "zones" crap in the FC world, provides user friendly names instead of numeric IDs, has encryption, 10Gb Ethernet can outperform even 8Gb FC, and even old 1GbE switches can perform adequately if port trunking is used properly.
What this all boils down to is that iSCSI is both better and cheaper than FC. Once popular SAN arrays from big vendors start to appear with 10GbE iSCSI as standard instead of an expensive "option", then FC will start to die a rapid and well deserved death.
Except that the trend for years now has been towards file formats that are already compressed.
All of the Office 2007 and later file formats are just zip files full of content. Try it, rename a '.docx' file to '.zip' and open it! Even Office 2003 can open these with a free plugin.
The OpenOffice ODF format is a zip file.
The Microsoft XPS format is a zip file.
Adobe PDF has had internal compression for a while.
Practically all image, audio, and video formats have been highly compressed for decades.
What kind of stone age file formats are in use at your corporation that additional compression is a huge benefit?
Where are you that you need to keep an eye on your bandwidth?
Where the hell are you that you can't even imaging having to worry about bandwith? Can I move there?
Over here in Australia, internet connections with 1GB quotas per month are not unusual, and most mobile 3G accounts are even more restricted.
In my experience, the easiest way to get a consistent and stable printing experience is by generating PDF. I have yet to have stability problems if this is done properly. As you're working with Ruby on Rails, using Prawn and Prawnto might be useful. However, if you absolutely positively must NOT use PDF for printing, then this probably won't help you.
I've just recently come across a similar problem. I had to emulate an old-school line printer for an application, with very precisely defined printing, a very specific font with DOS line drawing characters in it that had to line up, etc...
I found that by far the easiest method was to use Microsoft XPS. Generating it is a breeze, and it gives good control over layout. The client application is relatively light weight, which is a pleasant change. It's also trivial to embed an XPS reader into a client-side application, but it's hard with PDF. The client is written in a managed language, so it's got way fewer security holes than Adobe Acrobat, which is like swiss cheese in comparison.
The real problem is time. Even if you could check one move per Planck time (the shortest possible time interval, ca. 5*10^-44s), you'd still need about 5*10^79 seconds, or about 1.5*10^72 years. For comparison, the universe is about 1.5*10^9 years old.
You're forgetting that speed and parallelism aren't mutually exclusive!
If you could somehow convert all of the matter in the universe into a massively parallel computer running at that speed, with each CPU having a budget of ~40 million particles, then you'd have a computer that could play chess perfectly, providing each move in about 24 hours at first, and then probably speeding up a bit as the game progresses and there's less of the state space to check.
Your homework for tonight is to build two such computers using different methods, and compare the relative merits of each solution. Show your work.
Reminds me of a classic database developer nightmare story that I heard:
A local school was receiving complaints that two students were getting the exam results and the like mixed up.
The two students? Identical twins living in the same house, with the same name.. John Smith Jnr.
Apparently their father was John Smith Snr, and the whole "Senior / Junior" thing has been done for generations of "Johns Smiths", and it was a tradition and all, and we can't just break a tradition just because we had twin boys.. so... we'll name them both John Smith Jnr.
Thank you! I thought it was just me!
I did the same test a couple of years ago. I was writing an app for a huge data set, but I was told to do the proof-of-concept on both Oracle and SQL Server. I used two identical servers, identical SAN volumes, etc...
The result was shocking. Oracle is at least 5x as slow as SQL Server. It seems to pick acceptable query plans, but for some reason it's just... slower.
One possible explanation that occurred to me is that SQL Server clusters all data by default, whereas that's an optional 'feature' in Oracle. If you try to cluster data in Oracle, it can break other functionality, so it's not the default and developers can't always just turn it on.
Inserting bulk text seems to be awfully slow for some reason as well, and I couldn't figure it out. I saw forum posts along the lines of "well of course it's slow, you're working with text". Meanwhile, SQL Server was doing the exact same thing 50x faster.
Now I don't wonder any more why the Oracle EULA prohibits benchmarking.
Try googling for "Oracle Benchmark". You'll be lucky to find 2 or 3 on the entire internet that compare it to something else, and weren't done by Oracle themselves.
I thought I'd chime in.
Many countries worldwide are doing just fine without Nuclear Power. Check out New Zealand for one, http://en.wikipedia.org/wiki/Renewable_energy_in_New_Zealand
a) Electricity is only a small fraction of the total power used by a country. Think fertilisers, transport, and industrial energy, much of which is still oil or coal based even in countries where electricity is generated using nuclear or hydro power.
b) New Zealand is a very mountainous country with a low population density relative to the natural resources available, allowing much of their energy needs to be met using hydro. This just doesn't apply to most other countries. Here in Australia, we have a lot of hydro an wind based power as well, but it just doesn't add up to a large percentage. A lot of our power still comes from coal and oil.
This is like saying "we're lucky, maybe you should be luckier also, that'll solve your problems!"
Absolutely not! Snapshots are perfectly safe for capturing your database data.
On real server operating systems snapshot support is integrated into applications, which receive a "snapshot about to occur event" so they can quiesce their writes for a short period to make the snapshot clean.
For example, on a Windows server, a VSS snapshot is a complete restorable backup of everything, including your databases, event logs, the registry, etc... It's the standard mechanism that practically all Windows backup tools use. They take a snapshot, back it up, and then release it. The point in time that the snapshot was taken turns up in the "last backed up on" date field in SQL Server!
Even third party snapshot mechanisms integrate using plugins. If you take a snapshot with, say, VMware or your SAN, then the same quiescing mechanism is triggered.
Some real server operating systems like HP-UX appear to have LVM extensions that are similar to what VSS can do, but I can't find the equivalent in Linux. From what I can see, the closest you can get is to temporarily halt writes from the ext3 filesystem, but that's not the same thing as proper application quiescing.
Quoth Wikipedia:
4 January 2001 - Linux 2.4.0 was released (3,377,902 lines of code).
That's about the same as running Windows 2000 Server in a production environment.
someone with absolutely no experience with enterprise-level businesses
It's actually worse than that. People that should know are surprised:
Staples says companies have found alternate uses for tape, such as for nearline and offline storage.
Apparently it's news to Staple that companies began using table for offline storage about 60 years ago.
You get 1.5TB (3TB compressed) of LTO storage for about $120 in quantity. You stuff a pile of those in a library, configure the backup schedule and go home. The library tells you when to cycle out the tapes. It works really well and all the hardware and software costs less than what the guy who operates it gets paid in a quarter. Volume snapshots solved the last actual problems that this process ever had.
I just did a price comparison. According to a quick online price search, I can get an LTO 5 cartridge for about AUD 155 to AUD 200, but I can buy a Samsung 1.5TB hard drive delivered to my door for AUD 138!
A standalone LTO 5 tape drive has a minimum cost of $thousands, and even a low-cost autoloader is $thousands more.
Meanwhile, I can get a hot swap USB3 external drive box for about AUD 200 including the USB3 controller.
For any small business with less than 1.5TB of compressed data (2-4TB actual data), tapes are dead.
And don't tell me that tapes are somehow more reliable than hard drives, because they're not. A hard drive comes with it's own sealed steel box, and a tape will die just the same if you drop it onto a concrete floor.
What's much more important is that restoring to bare metal is much easier with a USB hard drive, particularly with Windows Server 2008 or later. The VHD backup images can be restored using the standard Windows installer CD. Because USB3 is backwards compatible with USB2 a restore can be done without any special drivers or software.
You know what isn't fun? Chasing down drivers for tape libraries at 3am.
Meanwhile, large corporations are moving to hard drives for different reasons. A chassis that can take ~48 SATA drives is now only 4 to 5 rack units. Even fully populated with 2TB drives it can end up cheaper than an empty tape library of the same capacity. Hard drives are much faster, allowing them to be used in more ways, such as single-instancing and simultaneous backups and restores. Many organisations now do incremental backups every couple of minutes to disk, which would be prohibitively difficult with tapes.
With single-instanced backups, the cost per TB swings towards hard drives in a big way. I've heard of 50:1 compression ratios in practice, and 250:1 is not outlandish. You'd have to buy LTO 5 media for a dollar each to match that!
All of the gains we make in hardware are eaten up as fast or faster than they are produced by two main consumers: useless eye-candy for end users, and higher and higher-level programming languages and tools that make it possible for developers to build increasingly inefficient and resource-hungry applications faster than before. And yes, I realize that there are irresistible market forces at work here, but that only applies to commercial software; for the FOSS world, it's a tremendous lost opportunity that appears to have been driven by little more than a desire to emulate corporate software development, which many FOSS developers admire for reasons known only to them and God.
This is a common misconception in the computing world: that somehow the additional computing power is 'wasted' on 'bloat'.
The basic principle that one has to understand is that in the meantime, human beings haven't changed. Our brains haven't improved in speed. There is no benefit to us if a program responds in 1 microsecond instead of 1 millisecond.
However, in terms of 'features', programs are still far behind where they should be. There's an awful lot that we as programmers could do that we aren't, either because it's too hard, or because the CPUs just couldn't handle it. Things like predictive text input, grammar checking, mixed languages in a single document, precise font-rendering, etc... make even simple applications like "word processors" very complex internally. All of this complexity makes it difficult to program in low-level languages, so programmers are moving towards easier to use high-level languages like Java and C#. This makes it easier to implement advanced features, at the cost of some performance.
In other words, programmers target a "constant" speed level determined by the properties of the human brain, while the computer hardware changes. This is a lot like the "time budget per frame" that game developers talk about. They target 60fps or 30fps for their games, giving a constant 16.6ms or 33.3ms to do all the required computations in for each frame. Year after year, in that amount of given wall-clock time, processors and video cards have been able to do more, so programmers take advantage of that added capability. There's no point in making a game run at 10,000fps, because humans can't perceive that!
Ordinary office and productivity applications are exactly the same. They target a certain level of responsiveness too, but the processors haven been getting faster, allowing programmers to do more in that time.