Network speeds? Nope. Back then, I had a 2400bps modem, and 9600bps was fairly common. Now, the most you can have is 56000bps (theoretical), only a 23x increase. Pathetic. Good thing we have broadband now, but that's an entirely different thing.
Why is it an entirely different thing? My cable modem is still a modem, right? FYI it does contain a modulator and a demodulator, thus making it a modem. Or do you think the difference between analog phone lines and coax is that big? Or is it the difference between digital signal sent between the computer and the modem over an RS-232 compared to sending it over ethernet? As far as I'm concerned, my cable modem has just as much to do with old phone modems, as a modern harddisk has to do with an antique harddisk. Sure, some interfaces have changed, but so has harddisk interfaces. From 9600bps to 26Mbps (the most my cable company offers), is a 2700x increase.
By the way, in 1991, you could probably buy the Intel 486 DX4 100Mhz, and larger harddisks were certainly available, although I guess 40MB was pretty typical of the PC market.
8 to 16 MB hard drive memory cache. With the memory cache that big many hard drive access operations are quite a bit faster.
Bah. I have 2GB of RAM. Most of it functions as disk cache. I'll be willing to bet that it gives me a lot more performance than the measly cache in the disk-drive. The cache in a hard drive is there simply because you need to store stuff before/after you transfer it across the SATA-bus. It can probably be calculated pretty precisely how much you need. Since this number is pretty small anyway, doubling or quadrupling it doesn't help performance much.
Unlike today's flash memory, these new solid-state storage devices can be written to trillions of times.
Now why would I want that? Assuming I overwrite the entire non-volatile high-speed solid state storage device once per second, a (US) trillion writes is going to take me 31710 years.
The purpose of not listing the number is so that google can charge the advertiser for this service.
That makes sense! Instead of increasing your prizes, you charge them for an additional service. It's like a real-estate investor renting out property for low prices, and then adding an extra payment in the form of "shared costs".
Also it acts as a protection against scammers who use your phone number as a way to ID you for nefarious purposes. If all you want to ask is "can your product do X?" you perhaps don't want them to know all of your identification.
If I don't trust them enough, to assume they're not phone number scammers, I sure as hell don't trust them with my money. My number is listed in the phonebook, so I don't see what good it would do them to collect numbers from callers. Also, I'm on the do-not-call list.
This isn't a feature so everyone can have free calls. This is something Google can show off to their Google Ad customers, to help them drive more revenue.
Obviously it is a feature so everyone can have free calls. If not, it would be easier to just list the phone-number to the advertiser, so I could call it myself.
The fact that I can only get free calls to someone who is trying to sell me something is the thing that drives googles revenue.
Is it something that I'm likely to ever use? No. Is it something that some marketers can be excited about? Probably. I trust google did some research before creating this service. Which makes me conclude that I have to become more cynical with regard to how many stupid people this planet contains. I could never be good in marketing, I have a tendency to assume people are intelligent.
"Silent" case, with room for extensions, easy access to things inside, and some USB-ports on the frontside. (Ignore cooling, all modern cases have adequate cooling for non-overclockers). There are plenty of good budget aluminium cases.
"Silent" overpowered powersupply with connectors that fit your motherboard. (Many hardware-failures come from faulty powersupplies, so get one with a bit more power than you need).
Motherboard with 939 socket, PCI-Express 16x (not AGP), a recent chipset (higher numbers are generally newer), and onboard gigabit ethernet. SLI is a marketing ploy (unless you are a fanatically rabid gamer with far too much money).
Athlon64 CPU in the lower-medium price-range (but consider going dual-core, in which case you should choose the lower-medium price-range of dualcore CPUs). The more expensive ones are not cost-effective unless you have very special needs...
Lot's of RAM (>= 1GB), as swapping to disk is too slow these days. (Choose moderately cheap DIMMs, from a known manufacturer). (It's better to buy large DIMMs right away, because nobody wants your small DIMMs if you choose to upgrade later (and there are only four slots)
Huge (>=200GB) S-ATA HD (possibly two, but don't use RAID, it's a hassle, and rarely noticeably faster. One disk for apps, and one for data works just as well). Fast disks might be worth it. Noise is also a factor, but if you worry that much about it, maybe you should invest in a watercooling system as well...
Cheap DVD burner (they're all good enough)
Graphic card in lower-medium price-range (unless you're a rabid gamer). nVidia works well enough on linux (there are no modern graphic cards with free drivers for linux).
Cheap soundcard or onboard sound (unless you're a musician) (Make sure it works with linux, the alsa project homepage has a compatibility page)
Flatscreen(s) with size according to budget. Large resolution is nice. Be aware of dead pixels, most manufacturers will not take them back if just "a few" pixels are dead.
Wireless mouse and keyboard. Microsoft actually makes some good ones.
Despite rumours to the contrary, a floppy is occationally useful, and it's dirt cheap.
Choose round cables for the inside. It's just so much nicer.
I've assumed you want an AMD CPU (AMD is best for general-purpose use, Intel is only better for specially hand-tuned code using SSE extensions (common in videoediting, some commercial soft-synths, etc...)).
In general, avoid features you have no need for now, and don't need in the future. Less features == higher reliability. Don't buy stuff that's suspiciously cheap (there's probably a reason for that). Don't buy stuff that's suspiciously expensive either (it's for enthusiasts and is not worth it).
From my readings in the relational data model and RDBMS theory, I learned that SQL is supposed to be a declarative lanuguage, which means, you tell the DBMS engine what you want done, and not how?
Yes, that's RDBMS theory.
Then the DBMS will use the path which is most optimized for the request.
In the real world, there is no such thing as "most optimized". Optimized for what? Reliability? Portability? Correctness? Features? Code maintenance? Speed? Memory usage? Disk usage? Throughput? Interactivity? Uptime? Least sysadmin work? I could probably go on, but I think you get the picture...
So, the fact that MySql is better for some tasks than Oracle, is a flaw in both engines, and supposedly one that both are working to fix.
Yes, but that doesn't mean that it's ever going to be fixed in either of the engines. The fact that buses have more space, and bicycles are easier to park, doesn't mean that one day we will have something that combines the advantages of both.
Just to give an example, since the user, doesn't see where and how his data is stored, Oracle for example, can use MySql's engine internally, when it detect situations for which MySql's engine is optimized, and switch to Oracle's engine, when the situation change, all hidden from the user, of course this is all in theory. It can be factually impossible to implement such a thing.
Just like it's factually impossible for the bus to use the bicycles internal engine when you decide it's time to find a parking spot.
How vulnerable are various projects to somebody buying the brains?
Probably not that much. Most of the brains aren't "for sale". They have their own interests that they work on, which they do, as long as it's still fun, and they have food on the table. A corporate sponsor might provide more time for their pet projects, thus making life easier for them, but it's the love of what they do, and their expertise of what they do, that's getting anything done at all. The corporate sponsing only helps.
Some notable projects might never have happened without corporate sponsors (e.g. openoffice or mono). But then we would have other alternatives that people worked on. Remember that before openoffice, there were dozen of wordprocessor/spreadsheet/presentation/office suite projects around. Some of them would eventually succeed. (even today, koffice seems pretty healthy). And before mono, there was lot's of talk of free java implementations (it still is), and lot's of other free languages and runtimes to choose from (it still is).
It's better to look at it as a healthy symbiotism, than a treath. It sure is good that we have corporate sponsors, but it's not like it would be the end of free software/open source, even if they all suddenly disappeared overnight.
If InnoDB contains patented technology that Oracle now owns as a result of their acquisition of InnoDB, isn't that a moot point since InnoDB already released that stuff under the GPL?
No. Repeat after me: "patents have nothing to do with copyright!". Write it on the chalkboard 100 times...
There could be patents covering the GPL-licensed code, which InnoDB might not have enforced. Of course, thinking in this way is almost paranoid, but it has happened before, remember GIF?
No matter how GPL'd the code is, if it violates patents, it is illegal to distribute in countries where that patent is valid. If you doubt me, the text of the GPL license itself spells this out for you. And even if you already have a copy, unless it comes with a patent license, it's illegal to run as well.
...is that you ask the wrong question. Whether people "feel good" or "feel bad" about dynamic allocation in "embedded applications" is completely uninteresting to you. What is interesting is whether it makes sense for your embedded application. And given the overwhelming lack of information you have provided about your project, the answer to that can only be known by you.
Since my company has run for the past 35+ years with no form of central IT department, there has been no standards put into place for developers to abide by.
Alright. Since your company has been able to run for the past 35+ years with no form of central IT department, you should not suddenly start to dictate standards for developers to abide by. At least things work now, so your primary objective should be to not break things.
Instead you should try to understand what the different groups are doing, and see how you can improve their processes incrementally. Some of the development teams might have very efficient practices in place. Some might have less efficient practices. Make them communicate and learn from each other.
One of my tasks is to set up standards in how projects will be implemented and produced.
Since your company has been doing this for 35+ years, no doubt your company is using the waterfall model. Your first task is to educate the medium and higher management on modern development practices. Your developers already know that stuff, but can't use it.
A company with 35+ years of development experience have plenty of talented people. You do not know what's best for everybody. Your job is to find out what works, and what doesn't work within the company, and preach the benefits of what works.
By assuming that "you know what's best", you ignore 35+ years of experience of a lot of talented people. Before you can "set up standards", you need to find a reasonable set of standards to implement.
There exists plenty of literature on how things should work in theory, but the fact is that within a given corporate environment (such as yours), those methodologies would barely work even on paper. Without a proven track record within the company, there is no way you can force people to do it your way! At best, you can encourage people to do it in a better way, but you can't force people to do it "your" way.
Right now I'm more concerned about trying to set up coding standards, so that any developer can jump into any part of a project and be able to figure out what's going on, without wasting a couple hours just to figure out the code.
Why on earth are you more concerned about that? While a "coding standard" can give some cosmetic feeling of order, you are in fact at a company with 35+ years of software archaeology to administer. There are more important issues right now than deciding how people should indent their code...
What do people like/dislike about how projects run in the company? How can it be improved? Which projects exists, and remains active? Should some of them be tossed? Can we toss some more old code? Can we get people to communicate better? Perhaps with a shared version control system? What are the needs of the developers with regard to IT services? Which corporate procedures creates the most hassles for developers? Etc...
A "coding standard" is a document that dictates developers to write their code in a certain way. It can either be ignored or followed. If it's ignored, it's harmless, but of no benefit. If it's followed, it can be a recipe for disaster. A bad coding standard is infinitely much worse than no coding standard at all. It is a straightjacket that forces the programmers to work in a certain way, whether it's productive or not! If, on the other hand, it's a good coding standard, it's benefits are little more than cosmetic. It might save a few hours here and there (as you claim), but those hours might be lost in having forced developers to follow it.
Besides being of limited benefit, writing a coding standard is one of the hardest things you can do. Different things work best for different people. You can't dictate what's best for them. You need to hear their opinions, find out what works best, and try to encourage people to do it in ways that are proven to work well within the company.
I've come across some documents in this area from a few sources (of
There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused.
Name one such processor feature. What on earth are you talking about?
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
Huh? You are not making sense. What does this have to do with portability? Are you talking about memory models or sizes of variables holding data. In either case it doesn't make any sense. Nobody "purposely uses a combination of 16-bit and 32 bit" because they want to be "portable". If they "purposely uses a combination of 16-bit and 32 bit", it's because that's what the spec says they should, or because the business logic dictates it.
I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware.
If you are talking about memory models, it's not just a performance advantage, it's an advantage. While a computer can do just about anything, there are things that are easy to do, and there are things that are not so easy to do. Mixing 16- and 32-bit memory models in a program is not easy, it introduces a lot of extra complexity, which will no doubt result in more bugs. It was pretty much what made windows 95/98/ME such a mess (and that was the operating systems division, which are paid to handle this sort of thing, imagine the troubles if someone in the app-division did the same!)
If you are talking about mixed-mode arithmetic with arguments of different data sizes, then one can argue that this is in fact a limitation of current hardware. But it's also a limitation that's here to stay. Making everything fast results in a combinatorial explosion of complexity in a CPU. The way it's done today is to either make it slow, or to make it impossible (i.e. require a 16-bit variable to be "promoted" to a 32-bit variable before calculations are done). This allows the common case to be fast, without making the processor more complex. It's likely to stay that way forever!
We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"
The purity is definitely worth it (as explained above). Whether it's worth it to replace working 32-bit systems with new 64-bit systems is an entirely different question. Do you need 64 bits now? Will you ever need it in the future? Will you need it within 1 year, or 10 years? How long do you plan to care for your systems? Are you working on embedded systems, desktop systems, or server systems? Etc...
32-bit systems are going to stay for a long time. Especially in the embedded space, where there is no imminent need for anything more.
For pretty much every modern problem that relis on heavy number crunching (like, e.g., anything based on FEM) you will benefit a lot from, say 128-bit (or 256-bit) native floating point operations even if address space still would be 64-bit.
Agreed. There's still room for improvement when it comes to floating point formats. While 2^63-1 is a ridiculously large number for integer calculations, with floating point, you will still see the benefit going from 64-bit to 256-bit. And then, there's also funkier things, like SIMD, and more futuristic improvements, like interval arithmetic in hardware.
Another use would be large number vector registers (to support which you would need wide internal bus) - so I could easily imagine useful "1024bit" processor which allows you to perform single cycle operations on multiple 1024-bit registers each holding, e.g., 1x1024/2x512/4x256/8x128/16x64 -bit values in 64-bit address space.
I very much doubt this is the way vector operations in the future will go. While it's the way they work on intel architectures now, it's not a particularly good way. MMX/3dnow/SSE is notorously difficult to actually make use of in real applications. Hopefully future improvements would be more programmer/compiler-friendly. The trick is to come up with an instruction set that the compiler can easily use, and that at the very least doesn't decrease performance when used in an obvious way.
Ah, you want a GC for the kernel. That's an entirely different thing, and not stupid at all. Even in linux, some data-structures are garbage-collected. What I objected to was making GC a kernel service that userspace programs could use. And believe me or not, I've seen people argue for this at numerous places, most of which, the people arguing for it should know better (unless what they *really* want is to take the kernel away, and have all applications written in a single, safe language with a certified compiler, e.g some ML-variant).
By the way, there's nothing forcing you to use C for kernel code. You are free to write your own OS kernel in whatever language you like, and many people have done so (including microsoft research). Even if you want to write linux kernel code, there's nothing forcing you to use C, as long as you can link it with gcc. You can use C++, Pascal, Ada, Fortran, Objective C, Java, or anything else gcc has a frontend for. Or you can use some other language, as long as you find a way to link your runtime environment, and some ffi-hooks into the kernel. It's only if you ever want your code accepted by linus, that you need to stay within C-land.
Garbage collection in the kernel is a stupid idea. Whenever you make a garbage collector implementation, it's tailored to a specific language, and a specific usage pattern.
E.g. a stack-based language would need a GC that needs how to scan the stack for pointers. But a stackless language may use the stack register as a general purpose register, and couldn't use the same implementation.
And even different stack-based languages, might use different layouts of the stack, meaning they either need different garbage collectors, an overly general parametrized garbage collector, or that they all need to be forced to use the same layout.
Different languages also use different object layouts. Some might tag all their objects with the information necessary for the GC. Others would need to rely on other static or dynamic guarantees about object layout. And even if we limit ourselves to fully tagged objects, a kernel based GC would need to force a particular way to tag them, something that again could force a certain object model onto every language.
There is also the very important difference between a stop-the-world collector, and a realtime GC. And if you want the collector to handle threads, you have yet another difference (actually the details here are really nasty). Are you mostly allocating short-lived objects, or long-lived? Does your heap size remain relatively constant, or does it grow and shrink a lot? Is your program short-lived, or is it long-lived? Do you worry more about fragmentation or about memory-locality of objects created in the same time-frame?
The list of policy decisions to make in a garbage collector is nearly endless. Each garbage collector must be tuned to the particular language it's intended for, and even then, there are usually different garbage collectors for different types of programs written in the language. Putting a GC in the kernel forces the same policy-decisions onto everyone, and I fail to see any benefit in that!
For example, if you want all 100 columns from a table, 'SELECT *' works quite nicely. However, if you want all but 1 of the 100 columns, be prepared to spell out 99 column names.
If this is your main problem with SQL, then you have other problems as well. Who in their right mind needs a table with 100 columns? If you have 100 columns, you seriously need to normalize your database.
Ok, I might not be a database buff. Actually, my experience with SQL is purely academical (although I've worked with object-oriented databases). But if I were to improve SQL, my attempts would be in the direction of making it into a more pure mapping of a relational database, not in adding yet more syntactic sugar.
And my point was that this kind of calculation is in practice not possible, and not desirable. Because you can't determine in advance how much it costs to find a "winner". In the end, the budget that research gets, is a combination of how much cash you have to spare, how much research has paid off in the past, and how much your competition is spending on research. The budget that a particular research project gets, is a combination of current fads in the budget committee, how well-written the grant-proposal was, how famous the researchers are, and various other more-or-less-random factors.
Let's say that currently, the Air Force can double its combat effectiveness with $1e9. Then say the invention allows the Air Force to double its combat effectiveness for $2e9.
Let's think the same way about developing, say, the jet engine. With enough propeller airplanes, we can double the airforce combat effectiveness. In fact, with enough stone-axes, we can probably win the war even without airplanes.
The modern western civilization is built on the idea, that research will eventually pay for itself. That it does, is not obvious at all, but if it weren't so, it wouldn't have been Europe that conquered all the other continents a few hundred years ago.
But research is also a drain on other resources. How much you spend on research should be determined by how much you can afford, not by how much it is going to gain you, because you simply can't calculate that. We can't give forecasts for future research, but we can expect that it will continue to give us advantages, as it has in the past.
If the research cost $1e9 and saves $1e9 20 years later, that's a loss, because you could have just put the $1e9 in a bank and let the interest accrue
That's assuming that a particular project like this can be isolated in this way, and that you have perfect ability to predict how small or large your savings will be in 20 years. If you do this for all projects that have a 20 year lifespan (which seems reasonable given your presumption), then no useful basic research will ever get done. This is not economically desirable (see above).
That's not all. You have to then divide by the success rate of the research. The research gains must pay for all research costs; you can't just just count the winners and ignore the losers. The winners must also recoup the cost of the losers.
Which is about the only thing I agree with you about;-)
Uhm, dude? The entire idea of the holding tank is illogical. Whales are mammals, they breathe air. We transport them out of water in trucks and aircraft. Put them in a sling, keep them wet and comfortable, and they're fine for short term transportation.
I'm sure that works for a small whale, and I know Keiko was transported that way. But Keiko was an orca, and orcas weigh up to 6 tons. A humpback whale weighs approximately 36 tons. That's a fairly beefy difference, and I wouldn't be surprised if a humpback can't survive out of water, as the body isn't strong enough to carry its own weight without the support of the surrounding water.
But then again, what do I know about humpback whale transportation aside from what I've learned from Star Trek;-)
But the point of the GP you responded to was that the article does not give such an analysis. That post was in response to someone claiming my questions were answered by the article "if I bothered to read it". I did bother to read it. And it simply doesn't give enough info to say if the research was worthwhile. That was all I was trying to say in the post.
Remember, it's not enough to say "technology X can do Y"; you must show it was preferable to the other uses of the resources used in developing and building it. A diamond-bladed lawnmower could be cost justified at some point for some use; I just use that as an example that's currently not, yet deceptively does "cool" things.
Well, then. Obviously you are an idiot, because your questions are wrong.
Obviously something that's stronger, faster, better, etc..., will be of use to someone. It means something that wasn't feasible before, is now possible.
Just because you are perfectly happy with glass in your frontshield window in your car, and don't need ALON, it doesn't mean that everybody is perfectly happy. Even if the army was perfectly happy using layers upon layers of bulletproof glass (which they obviously aren't since they're paying for this), doesn't mean that other applications don't exist. It could be used in submarines, airplaines, or spaceships, or who the hell cares! Applications will obviously come that can utilize it and justify its costs, and once into production, it will become cheaper, and eventually, you'll find it on the cover of your cellphone, and on your wristwatch!
If you carry out this kind of cost-analysis on all research, almost no research will be done. To take the diamond-bladed lawnmower example. While completely silly, once you have the ability to make diamond blades for lawnmowers, you also have the ability to make diamond-blades (and probably other surfaces) for other stuff. For one thing, I'm sure the oil-industry would be happy, and they can afford it! And so would, and could, a lot of other industries!
If you have trouble imagining uses for something that's so obviously an improvement in material science, I really hope you will never be in a position to influence that kind of decisions. Now, if this was purely applied research just for the purpose of creating a better bulletproof glass, the money could conceivably be wasted, but that's only if the beancounters at the airforce were so stupid as to keep it a secret. By licensing it to other commercial venues, they can get back their costs tenfold.
And we still haven't covered the value of the basic research done, which most likely will lead to other, related breakthroughs in material science (just as the Kroll-process for manufacturing titanium, could also be used for manufacturing zirconium (used in nuclear reactors, chemical plants, etc..))
but it does mean that your argument needs a more substansial backing before other objective, intelligent people and I drink your Kool-Aid.
Actually, it was not an argument. It was an observation. And it's an observation I stand by, untill someone can come up with substantial good arguments the other way. Such arguments would include statistics that show that people who smoke pot regularly, have similar income, education, etc.. as non-pot smokers.
There will always be exceptions to the rule, so anecdotes are not acceptible "evidence". Alcohol doesn't make you smarter either, but lot's of clever people were alcoholics.
As to you having a book published, congratulations. But it doesn't necessarily mean you're smart. This guy has gotten plenty of books published, but..., well you get my point...
Um, ok. So like video games are an analogy, right?
Yes, certainly. Playing video games isn't exactly what I would call "productive". It's an unproductive asocial waste of time. The only positive side is that it will bring you a little bit of fun. If playing computer games start becoming an important part of your life, it's time to stop. If you are doing it as harmless recreation, who cares?
And computer programmers? They don't have lives, right? Unhappy and all that?
The difference with computer programmers and gamers/dope-heads is that computer programmers actually produce something useful for society. This in turn, could bring them some benefit, typically money. Thus it's not a "just waste of time", although if computer programming becomes addictive, and you find yourself programming late-nighters all the time without giving sufficient time for other tasks, it could be harmful to other goals you have.
Marijuana, like all potentially fun experiences, attracts "stupid people." Stupid people have a right to live, too.
Stupid people certainly have a right to live. Now, if someone was stupid, and they asked for advice for how to get the most out of life, my answer would not be "marihuana". Would yours?
Much like it attracts smart people.
I seriously doubt that. Just because you can produce a list of smart people who used marihuana, doesn't mean that smart people generally use marihuana. Nor that it "attracts smart people". Smart people generally stay away from mariuhana because (a) it's illegal (b) they think dopers are annoying.
Also, stupid people are worse at hiding that they do illegal things. So maybe that's a factor.
Most likely.
Here's my question. Should I use Xanax instead?
If your doctor prescribed it to you to cure an anxiety disorder, then most likely: yes. If you are talking about recreational purposes, I would prefer you to use marihuana.
Slashdot Mirror
Why is it an entirely different thing? My cable modem is still a modem, right? FYI it does contain a modulator and a demodulator, thus making it a modem. Or do you think the difference between analog phone lines and coax is that big? Or is it the difference between digital signal sent between the computer and the modem over an RS-232 compared to sending it over ethernet? As far as I'm concerned, my cable modem has just as much to do with old phone modems, as a modern harddisk has to do with an antique harddisk. Sure, some interfaces have changed, but so has harddisk interfaces. From 9600bps to 26Mbps (the most my cable company offers), is a 2700x increase.
By the way, in 1991, you could probably buy the Intel 486 DX4 100Mhz, and larger harddisks were certainly available, although I guess 40MB was pretty typical of the PC market.
Bah. I have 2GB of RAM. Most of it functions as disk cache. I'll be willing to bet that it gives me a lot more performance than the measly cache in the disk-drive. The cache in a hard drive is there simply because you need to store stuff before/after you transfer it across the SATA-bus. It can probably be calculated pretty precisely how much you need. Since this number is pretty small anyway, doubling or quadrupling it doesn't help performance much.
Unlike today's flash memory, these new solid-state storage devices can be written to trillions of times.
Now why would I want that? Assuming I overwrite the entire non-volatile high-speed solid state storage device once per second, a (US) trillion writes is going to take me 31710 years.
Wow, you're a genius! This is why I could never succeed in marketing!
Agreed 100%. You explained my frustration perfectly.
Yes.
That makes sense! Instead of increasing your prizes, you charge them for an additional service. It's like a real-estate investor renting out property for low prices, and then adding an extra payment in the form of "shared costs".
Also it acts as a protection against scammers who use your phone number as a way to ID you for nefarious purposes. If all you want to ask is "can your product do X?" you perhaps don't want them to know all of your identification.
If I don't trust them enough, to assume they're not phone number scammers, I sure as hell don't trust them with my money. My number is listed in the phonebook, so I don't see what good it would do them to collect numbers from callers. Also, I'm on the do-not-call list.
Obviously it is a feature so everyone can have free calls. If not, it would be easier to just list the phone-number to the advertiser, so I could call it myself.
The fact that I can only get free calls to someone who is trying to sell me something is the thing that drives googles revenue.
Is it something that I'm likely to ever use? No. Is it something that some marketers can be excited about? Probably. I trust google did some research before creating this service. Which makes me conclude that I have to become more cynical with regard to how many stupid people this planet contains. I could never be good in marketing, I have a tendency to assume people are intelligent.
I've assumed you want an AMD CPU (AMD is best for general-purpose use, Intel is only better for specially hand-tuned code using SSE extensions (common in videoediting, some commercial soft-synths, etc...)).
In general, avoid features you have no need for now, and don't need in the future. Less features == higher reliability. Don't buy stuff that's suspiciously cheap (there's probably a reason for that). Don't buy stuff that's suspiciously expensive either (it's for enthusiasts and is not worth it).
Yes, that's RDBMS theory.
Then the DBMS will use the path which is most optimized for the request.
In the real world, there is no such thing as "most optimized". Optimized for what? Reliability? Portability? Correctness? Features? Code maintenance? Speed? Memory usage? Disk usage? Throughput? Interactivity? Uptime? Least sysadmin work? I could probably go on, but I think you get the picture...
So, the fact that MySql is better for some tasks than Oracle, is a flaw in both engines, and supposedly one that both are working to fix.
Yes, but that doesn't mean that it's ever going to be fixed in either of the engines. The fact that buses have more space, and bicycles are easier to park, doesn't mean that one day we will have something that combines the advantages of both.
Just to give an example, since the user, doesn't see where and how his data is stored, Oracle for example, can use MySql's engine internally, when it detect situations for which MySql's engine is optimized, and switch to Oracle's engine, when the situation change, all hidden from the user, of course this is all in theory. It can be factually impossible to implement such a thing.
Just like it's factually impossible for the bus to use the bicycles internal engine when you decide it's time to find a parking spot.
Probably not that much. Most of the brains aren't "for sale". They have their own interests that they work on, which they do, as long as it's still fun, and they have food on the table. A corporate sponsor might provide more time for their pet projects, thus making life easier for them, but it's the love of what they do, and their expertise of what they do, that's getting anything done at all. The corporate sponsing only helps.
Some notable projects might never have happened without corporate sponsors (e.g. openoffice or mono). But then we would have other alternatives that people worked on. Remember that before openoffice, there were dozen of wordprocessor/spreadsheet/presentation/office suite projects around. Some of them would eventually succeed. (even today, koffice seems pretty healthy). And before mono, there was lot's of talk of free java implementations (it still is), and lot's of other free languages and runtimes to choose from (it still is).
It's better to look at it as a healthy symbiotism, than a treath. It sure is good that we have corporate sponsors, but it's not like it would be the end of free software/open source, even if they all suddenly disappeared overnight.
No. Repeat after me: "patents have nothing to do with copyright!". Write it on the chalkboard 100 times...
There could be patents covering the GPL-licensed code, which InnoDB might not have enforced. Of course, thinking in this way is almost paranoid, but it has happened before, remember GIF?
No matter how GPL'd the code is, if it violates patents, it is illegal to distribute in countries where that patent is valid. If you doubt me, the text of the GPL license itself spells this out for you. And even if you already have a copy, unless it comes with a patent license, it's illegal to run as well.
...is that you ask the wrong question. Whether people "feel good" or "feel bad" about dynamic allocation in "embedded applications" is completely uninteresting to you. What is interesting is whether it makes sense for your embedded application. And given the overwhelming lack of information you have provided about your project, the answer to that can only be known by you.
Alright. Since your company has been able to run for the past 35+ years with no form of central IT department, you should not suddenly start to dictate standards for developers to abide by. At least things work now, so your primary objective should be to not break things.
Instead you should try to understand what the different groups are doing, and see how you can improve their processes incrementally. Some of the development teams might have very efficient practices in place. Some might have less efficient practices. Make them communicate and learn from each other.
One of my tasks is to set up standards in how projects will be implemented and produced.
Since your company has been doing this for 35+ years, no doubt your company is using the waterfall model. Your first task is to educate the medium and higher management on modern development practices. Your developers already know that stuff, but can't use it.
A company with 35+ years of development experience have plenty of talented people. You do not know what's best for everybody. Your job is to find out what works, and what doesn't work within the company, and preach the benefits of what works.
By assuming that "you know what's best", you ignore 35+ years of experience of a lot of talented people. Before you can "set up standards", you need to find a reasonable set of standards to implement.
There exists plenty of literature on how things should work in theory, but the fact is that within a given corporate environment (such as yours), those methodologies would barely work even on paper. Without a proven track record within the company, there is no way you can force people to do it your way! At best, you can encourage people to do it in a better way, but you can't force people to do it "your" way.
Right now I'm more concerned about trying to set up coding standards, so that any developer can jump into any part of a project and be able to figure out what's going on, without wasting a couple hours just to figure out the code.
Why on earth are you more concerned about that? While a "coding standard" can give some cosmetic feeling of order, you are in fact at a company with 35+ years of software archaeology to administer. There are more important issues right now than deciding how people should indent their code...
What do people like/dislike about how projects run in the company? How can it be improved? Which projects exists, and remains active? Should some of them be tossed? Can we toss some more old code? Can we get people to communicate better? Perhaps with a shared version control system? What are the needs of the developers with regard to IT services? Which corporate procedures creates the most hassles for developers? Etc...
A "coding standard" is a document that dictates developers to write their code in a certain way. It can either be ignored or followed. If it's ignored, it's harmless, but of no benefit. If it's followed, it can be a recipe for disaster. A bad coding standard is infinitely much worse than no coding standard at all. It is a straightjacket that forces the programmers to work in a certain way, whether it's productive or not! If, on the other hand, it's a good coding standard, it's benefits are little more than cosmetic. It might save a few hours here and there (as you claim), but those hours might be lost in having forced developers to follow it.
Besides being of limited benefit, writing a coding standard is one of the hardest things you can do. Different things work best for different people. You can't dictate what's best for them. You need to hear their opinions, find out what works best, and try to encourage people to do it in ways that are proven to work well within the company.
I've come across some documents in this area from a few sources (of
Good luck doing just that!
Name one such processor feature. What on earth are you talking about?
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
Huh? You are not making sense. What does this have to do with portability? Are you talking about memory models or sizes of variables holding data. In either case it doesn't make any sense. Nobody "purposely uses a combination of 16-bit and 32 bit" because they want to be "portable". If they "purposely uses a combination of 16-bit and 32 bit", it's because that's what the spec says they should, or because the business logic dictates it.
I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware.
If you are talking about memory models, it's not just a performance advantage, it's an advantage. While a computer can do just about anything, there are things that are easy to do, and there are things that are not so easy to do. Mixing 16- and 32-bit memory models in a program is not easy, it introduces a lot of extra complexity, which will no doubt result in more bugs. It was pretty much what made windows 95/98/ME such a mess (and that was the operating systems division, which are paid to handle this sort of thing, imagine the troubles if someone in the app-division did the same!)
If you are talking about mixed-mode arithmetic with arguments of different data sizes, then one can argue that this is in fact a limitation of current hardware. But it's also a limitation that's here to stay. Making everything fast results in a combinatorial explosion of complexity in a CPU. The way it's done today is to either make it slow, or to make it impossible (i.e. require a 16-bit variable to be "promoted" to a 32-bit variable before calculations are done). This allows the common case to be fast, without making the processor more complex. It's likely to stay that way forever!
We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"
The purity is definitely worth it (as explained above). Whether it's worth it to replace working 32-bit systems with new 64-bit systems is an entirely different question. Do you need 64 bits now? Will you ever need it in the future? Will you need it within 1 year, or 10 years? How long do you plan to care for your systems? Are you working on embedded systems, desktop systems, or server systems? Etc...
32-bit systems are going to stay for a long time. Especially in the embedded space, where there is no imminent need for anything more.
Agreed. There's still room for improvement when it comes to floating point formats. While 2^63-1 is a ridiculously large number for integer calculations, with floating point, you will still see the benefit going from 64-bit to 256-bit. And then, there's also funkier things, like SIMD, and more futuristic improvements, like interval arithmetic in hardware.
Another use would be large number vector registers (to support which you would need wide internal bus) - so I could easily imagine useful "1024bit" processor which allows you to perform single cycle operations on multiple 1024-bit registers each holding, e.g., 1x1024/2x512/4x256/8x128/16x64 -bit values in 64-bit address space.
I very much doubt this is the way vector operations in the future will go. While it's the way they work on intel architectures now, it's not a particularly good way. MMX/3dnow/SSE is notorously difficult to actually make use of in real applications. Hopefully future improvements would be more programmer/compiler-friendly. The trick is to come up with an instruction set that the compiler can easily use, and that at the very least doesn't decrease performance when used in an obvious way.
By the way, there's nothing forcing you to use C for kernel code. You are free to write your own OS kernel in whatever language you like, and many people have done so (including microsoft research). Even if you want to write linux kernel code, there's nothing forcing you to use C, as long as you can link it with gcc. You can use C++, Pascal, Ada, Fortran, Objective C, Java, or anything else gcc has a frontend for. Or you can use some other language, as long as you find a way to link your runtime environment, and some ffi-hooks into the kernel. It's only if you ever want your code accepted by linus, that you need to stay within C-land.
E.g. a stack-based language would need a GC that needs how to scan the stack for pointers. But a stackless language may use the stack register as a general purpose register, and couldn't use the same implementation.
And even different stack-based languages, might use different layouts of the stack, meaning they either need different garbage collectors, an overly general parametrized garbage collector, or that they all need to be forced to use the same layout.
Different languages also use different object layouts. Some might tag all their objects with the information necessary for the GC. Others would need to rely on other static or dynamic guarantees about object layout. And even if we limit ourselves to fully tagged objects, a kernel based GC would need to force a particular way to tag them, something that again could force a certain object model onto every language.
There is also the very important difference between a stop-the-world collector, and a realtime GC. And if you want the collector to handle threads, you have yet another difference (actually the details here are really nasty). Are you mostly allocating short-lived objects, or long-lived? Does your heap size remain relatively constant, or does it grow and shrink a lot? Is your program short-lived, or is it long-lived? Do you worry more about fragmentation or about memory-locality of objects created in the same time-frame?
The list of policy decisions to make in a garbage collector is nearly endless. Each garbage collector must be tuned to the particular language it's intended for, and even then, there are usually different garbage collectors for different types of programs written in the language. Putting a GC in the kernel forces the same policy-decisions onto everyone, and I fail to see any benefit in that!
If this is your main problem with SQL, then you have other problems as well. Who in their right mind needs a table with 100 columns? If you have 100 columns, you seriously need to normalize your database.
Ok, I might not be a database buff. Actually, my experience with SQL is purely academical (although I've worked with object-oriented databases). But if I were to improve SQL, my attempts would be in the direction of making it into a more pure mapping of a relational database, not in adding yet more syntactic sugar.
Let's say that currently, the Air Force can double its combat effectiveness with $1e9. Then say the invention allows the Air Force to double its combat effectiveness for $2e9.
Let's think the same way about developing, say, the jet engine. With enough propeller airplanes, we can double the airforce combat effectiveness. In fact, with enough stone-axes, we can probably win the war even without airplanes.
The modern western civilization is built on the idea, that research will eventually pay for itself. That it does, is not obvious at all, but if it weren't so, it wouldn't have been Europe that conquered all the other continents a few hundred years ago.
But research is also a drain on other resources. How much you spend on research should be determined by how much you can afford, not by how much it is going to gain you, because you simply can't calculate that. We can't give forecasts for future research, but we can expect that it will continue to give us advantages, as it has in the past.
If the research cost $1e9 and saves $1e9 20 years later, that's a loss, because you could have just put the $1e9 in a bank and let the interest accrue
That's assuming that a particular project like this can be isolated in this way, and that you have perfect ability to predict how small or large your savings will be in 20 years. If you do this for all projects that have a 20 year lifespan (which seems reasonable given your presumption), then no useful basic research will ever get done. This is not economically desirable (see above).
That's not all. You have to then divide by the success rate of the research. The research gains must pay for all research costs; you can't just just count the winners and ignore the losers. The winners must also recoup the cost of the losers.
Which is about the only thing I agree with you about ;-)
I'm sure that works for a small whale, and I know Keiko was transported that way. But Keiko was an orca, and orcas weigh up to 6 tons. A humpback whale weighs approximately 36 tons. That's a fairly beefy difference, and I wouldn't be surprised if a humpback can't survive out of water, as the body isn't strong enough to carry its own weight without the support of the surrounding water.
But then again, what do I know about humpback whale transportation aside from what I've learned from Star Trek ;-)
Remember, it's not enough to say "technology X can do Y"; you must show it was preferable to the other uses of the resources used in developing and building it. A diamond-bladed lawnmower could be cost justified at some point for some use; I just use that as an example that's currently not, yet deceptively does "cool" things.
Well, then. Obviously you are an idiot, because your questions are wrong.
Obviously something that's stronger, faster, better, etc..., will be of use to someone. It means something that wasn't feasible before, is now possible.
Just because you are perfectly happy with glass in your frontshield window in your car, and don't need ALON, it doesn't mean that everybody is perfectly happy. Even if the army was perfectly happy using layers upon layers of bulletproof glass (which they obviously aren't since they're paying for this), doesn't mean that other applications don't exist. It could be used in submarines, airplaines, or spaceships, or who the hell cares! Applications will obviously come that can utilize it and justify its costs, and once into production, it will become cheaper, and eventually, you'll find it on the cover of your cellphone, and on your wristwatch!
If you carry out this kind of cost-analysis on all research, almost no research will be done. To take the diamond-bladed lawnmower example. While completely silly, once you have the ability to make diamond blades for lawnmowers, you also have the ability to make diamond-blades (and probably other surfaces) for other stuff. For one thing, I'm sure the oil-industry would be happy, and they can afford it! And so would, and could, a lot of other industries!
If you have trouble imagining uses for something that's so obviously an improvement in material science, I really hope you will never be in a position to influence that kind of decisions. Now, if this was purely applied research just for the purpose of creating a better bulletproof glass, the money could conceivably be wasted, but that's only if the beancounters at the airforce were so stupid as to keep it a secret. By licensing it to other commercial venues, they can get back their costs tenfold.
And we still haven't covered the value of the basic research done, which most likely will lead to other, related breakthroughs in material science (just as the Kroll-process for manufacturing titanium, could also be used for manufacturing zirconium (used in nuclear reactors, chemical plants, etc..))
Actually, it was not an argument. It was an observation. And it's an observation I stand by, untill someone can come up with substantial good arguments the other way. Such arguments would include statistics that show that people who smoke pot regularly, have similar income, education, etc.. as non-pot smokers.
There will always be exceptions to the rule, so anecdotes are not acceptible "evidence". Alcohol doesn't make you smarter either, but lot's of clever people were alcoholics.
As to you having a book published, congratulations. But it doesn't necessarily mean you're smart. This guy has gotten plenty of books published, but..., well you get my point...
Ever heard of the "exception that confirms the rule"?
Yes, certainly. Playing video games isn't exactly what I would call "productive". It's an unproductive asocial waste of time. The only positive side is that it will bring you a little bit of fun. If playing computer games start becoming an important part of your life, it's time to stop. If you are doing it as harmless recreation, who cares?
And computer programmers? They don't have lives, right? Unhappy and all that?
The difference with computer programmers and gamers/dope-heads is that computer programmers actually produce something useful for society. This in turn, could bring them some benefit, typically money. Thus it's not a "just waste of time", although if computer programming becomes addictive, and you find yourself programming late-nighters all the time without giving sufficient time for other tasks, it could be harmful to other goals you have.
Marijuana, like all potentially fun experiences, attracts "stupid people." Stupid people have a right to live, too.
Stupid people certainly have a right to live. Now, if someone was stupid, and they asked for advice for how to get the most out of life, my answer would not be "marihuana". Would yours?
Much like it attracts smart people.
I seriously doubt that. Just because you can produce a list of smart people who used marihuana, doesn't mean that smart people generally use marihuana. Nor that it "attracts smart people". Smart people generally stay away from mariuhana because (a) it's illegal (b) they think dopers are annoying.
Also, stupid people are worse at hiding that they do illegal things. So maybe that's a factor.
Most likely.
Here's my question. Should I use Xanax instead?
If your doctor prescribed it to you to cure an anxiety disorder, then most likely: yes. If you are talking about recreational purposes, I would prefer you to use marihuana.