Even more to the point... You don't find and/or exploit 'MBA' types. They come find you and exploit you. That is their nature - they have the drive, the ability to control people, and the willingness to take risk and stay on the ball. If you want to focus on your technical and operational interests, that is fine, but you will play second fiddle to those that assume command. Likewise, there is nothing unethical about said people who maintain control. That is just human nature's way of creating a productive society. PHB's have more value than a lot of geeks admit, even if they are boneheaded about anything technical or intellectual.
On the flip side, I wouldn't spend too much time on/. looking for technical talent because of the low signal to noise ratio.
Can you back up your assertion that silver-backed currency is superior, in contrast to the fact that all major economies/ nations use a fiat-currency? Despite the faults of backed currency, how is it still better??? The only arguable point is that is helps to keep inflation low, but that isn't guaranteed, and there are more problems than benefits like I mentioned. Other problems that it causes are trade imbalances and limited money supply (think required reserve ratio or the lack of).
The major complaint with fiat-money is that it can lead to inflation because the supply is state-controlled. That is true for nations without sound fiscal policy. The Dollar is strong and so widely used in foreign markets due to the US's commitment to sound policy (though you may disagree on political grounds if you are a Libertarian, the policy is sound.)
Dual currency is a huge problem. It's bad enough when I get slipped a Canadian quarter that I can't put it a vending machine. I know 'Liberty Dollars' claim to be redeemable in '95% of stores'. I flat-out don't believe that, and would be fearful of converting my money to a largely unrecognized system. Do you really want every cashier to be an expert on every possible currency in circulation??
Interesting. But unfortunately, the proponents of this missed too many economic classes to understand why its a bad idea. It's not inflation proof just because it's backed by some arbitrary precious good. In fact that creates more harm than good, which is why the US gave up on the Silver/Gold Standards. I.e. if someone finds new lodes of gold then your monetary value goes to hell. You will have liquidity issues as well, which is what money is supposed to prevent in the first place. That means that people will experience barriers to trade when they have to find a common currency to use. It's like trying to get a bunch of Linux geeks to agree on a common distribution. The Fed keeps this to a minimum by forcing us to use one common currency.
Also, if I'm not mistaken, it's unconstitutional in the US to have arbitrary monetary systems besides the dollar.
Don't forget Econ 101. Alternates and substitutes have as much effect on price. i.e. the cost of building Linux from the ground-up, or using a substitute BSD-liscensed product. like.. oh.. say.. BSD.
This while thing looks shady though.. A post on some board for a $50K deal?
Exactly, as a contractor you will still have a boss (either your customers or yourself) that you have to answer to. This means that you won't get paid to do whatever you want to do. You need to have the discipline to understand and execute your customer's requirements.
If you are just looking for a creative outlet to express yourself, get a regular job doing whatever you can. Do what you love on your time as a hobby, and for your own education. You will be happier with this situation, because nothing takes the fun out of programming faster than having to make money at it.
If you are very good, have a big professional network, and 20 years of experience, then you might make more than you would working for someone else. As much as you think your boss is clueless (my employment experience is no exception), having a company to work within adds much economic value that you can't provide directly to your customers if you were independant.
I agree with you, but good process doesn't bore me at all. But I know I'm the exception. The truth is Managagment just wants to get the job done with the least resources, so they pressure the techs with increasing workload and tend to look the other way when people cut corners to get the job done. Techs know they are supposed to do process 100%, but they don't want to be the guy who takes twice as long to do stuff because of following procss. So whenever I see major screw ups like this, I blame management and ops equally.
Engineers, BTW, write processes but never follow their own process. Thus, they leave messes for the techs to sort out.
That's not how a software firewall is supposed to work. Either Microsoft doesn't get it, or they are trying to dumb it down so the average user feels like they are protected, but really aren't.
Software firewalls can either block outgoing connections from spyware or untrusted apps to keep data leaking out of your machine from within. Just get Zonealarm or equivalent, and your problems are solved. Programs must ask for permission before accessing the network. MS firewall didn't ever seem to do this when I tried it. Software firewalls can also actively filter content coming and going through known connections like HTTP. But this isn't as foolproof.
Microsoft's firewall, in my experience, does nothing except take you machine off the network. Big deal I can get the same effect by unplugging my ethernet cable, thank you.
To make a firewall that 'keeps people from breaking into my machine' is asinine. If you don't want someone accessing a service, you turn it off or change it's configuration to deny specific external hosts. If there are holes in the OS that a hacker can exploit, then a firewall is only a band-aid, that may or may not work. And it isn't any help if you actually intend to run services on you machine.
good points, and they help to demonstrate the trade-offs in transitioning to superconductors. The main issue is that superconductivity isn't a slam dunk, and it doesn't equal 100% efficiency. I think the article was just too rosy saying how revolutionary superconductors will be. The diminising returns of 1% efficiency improvment (claimed in the article) and smaller motors on a large ship may not justify the high maintainance and design costs of a superconducting system. I'd like to see how much plumbing and equipment is needed to provide ongoing cryogenic cooling.
After reading the arcticle, the reason why these motors can achieve higher density is because the thermal dissapation issues are reduced when you don't have DC losses in your coil windings.
You are right as far as lower freqencies needing more core material. But, I can't see how superconductors would change that equation at all. Even if the superconductor carries more current, the magnetic material has the same basic flux energy storage capacity. Ships tend to use higher frequencies anyway, such as 400Hz, so frequency probably isn't the problem. In a propulsion system, the design engineers are probably allowed to choose any frequency they want. Also, superconductors don't eliminate all loses. Core losses are still going to be an issue unless the motor design is significantly different than anything seen before, or uses superconducting mu-metal.
You can always make a slower, higher torque high-frequency direct-drive sync motor by adding more poles. But you can't make a low-freq motor faster. i.e. top speed for a 2-pole 60Hz sync motor is 3600 RPM.
Also, from what I remember, superconductors tend to lose superconductivity in strong magnetic fields. Hopefully, they have worked around that problem.
exactly. There is a matrix of capacitors with only drive cicuits (transistors) at the end of the rows and columns. That is basically why computer designs always go with the relatively slow DRAM for mass memory due to its compact and economical nature. If you are designing a system that needs speed (like a cache or video device) you will always go with SRAM. But exect to pay _hundreds_ of times more per MB, and expect to have a way more physical address lines to contend with.
Also, answering some of the other posts above, DRAM with bad cells will get downgraded by chopping off rows containing bad cells. So you might take a 32Mx32 chip and make it 32Mx16. Depending on the nature of the defects, the chip might be downgraded for non-critical use in things like digital answering machines which can tolerate a few bad bits in the data stream. I dont think downgrading the speed helps much though as far as bad individual bits.
It is actually way easier to make hydrogen fuel via electrolosis than it is to make an efficient and practical fuel cell.
All you need is some water with electrolyte. NaOH works the best because, unlike NaCl, it won't outgas anything except pure hydrogen and oxygen. Common salt will outgass poisonous levels of chlorine gas, so don't even try it. Then you just need a DC current of low voltage, and some inert electrodes (graphite rods work great). Hydrogen (H2) gas collects at one of the electrodes (I'll let you do the half-cell equation to figure out which.) Then just deal with some physical issues like collecting the H2 gas SAFELY.
The problem is that you often don't know how much buffer a function call will require. If a function expects a buffer to be passed in (as a reference), then it is essentially a fixed buffer whether you created it using myBuff[100] or malloc(100*sizeof(someDataType)). That is often the problem C programmers face and there isnt a good solution if the code you are forced to use is crappily designed.
The correct ways of handing off a buffer are one of the following:
1.) dont use crappy function calls like the above for any reason. If that is what was handed to you, complain.
2.) In C++, use a CString, assuming the function you are calling supports it.
3.) Only use function calls that support a counted buffer of some type:
a.) Some function calls expect to be called twice, or have a helper function - once to get the exact buffer length, then again (once you have created that buffer) to fill it.
b.) only use the strn versions of a function, where You specifiy the length of the buffer.
c.) You could pass in a null terminated buffer, but only if the buffer would never contain a zero other than the terminator, and that you know that the function you call will check for that terminator, and never over-run it. Best to avoid this. This function would also have to somehow tell you that it needs to be called again to get any remaining data.
But the parent is correct: Buffer overflows are caused by lazy coders. Coders who assume that an input will be of a certain length, or 'should probably never be longer than this big number I just picked' are crappy programmers, and are not worth their salt. It is tedious to write code properly, and requires disipline, review, and testing. Not something most managers want to deal with either.
Like all things, the answer is someplace in the middle. This article was way too Utopian. OTOH, saying that privatization is all bad is wrong also.
A agree with what you said, if we could do what the article states with re-using spectrum, then there wouldn't be any argument at all. The reality is that there are a few tricks to multiplex the spectrum, but it's still finite. You can do things like directional antennas, and digital spread spectrum can co-exist with modulated transmission. But, the work of Shannon and Nyquist put very hard limits on the maximum throughput of a channel with real-world noise. The analogy that the human ear can pick one conversation out of n-others simply isn't true. The author hasn't, apparently, been to a party where you keep having to say: 'huh?', 'what?'. Add more background conversations/noise (Shannon) and the throughput falls off. I can sort of see how you could discriminate 'conversations' with the right protocols, but the idea that it is infinite is very bad science. I believe the human ear works very similar to spread spectrum technology, but also draws from syllable information stored in the mind's knowledge base to discriminate conversations. The point is that it isn't a miracle, and still has physical limits.
There is definitely much wasted spectrum because the government has put it out of reach of any economic pressures. But there needs to be some central control because the invisible hand of the economy isn't intelligent enough to correctly plan certain aspects of spectrum allocation. Also, interactivity of devices requires some authoritarian control even if it isn't 100% efficient. Set aside spectrum for military and public services. Let the rest be traded and sold commercially. The FCC should still be involved in the facilitation of these transactions for 2 reasons. 1. its the equivalent of keeping public deeds on property - there needs to be an authoritative unbiased record stored someplace. 2. There will be times that proposals need to be rejected because of technical incompatibilities. The 2 parties in a transaction may not care about an issue that would effect a third party.
I don't think spectrum fragmentation will be a problem at all. There will be strong economic pressure to keep chunks of spectrum together. There will be capitalists who act as consolidators if there is value in having unfragmented spectrum.
I totally agree, I was going to post the same idea. AI research has been tripping and falling down over the same damn problem for half a century because computer scientists in that area cannot see the futility of the symbolic approach. (The semantic web is a very structured approach to ill defined human/real-world data.) I thought research of the 1990's finally put the nail in the coffin with 'fuzzy' approaches such as neural nets et. al.
Even if the semantic web was technically viable (it isn't), the human factors would kill it:
1. Major tech companies will corrupt and pervert the standards and intended usage.
2. Overworked and underskilled web page designers will write broken semantic 'code' because they just want the page to look a certain way. They won't care about keeping a parallel set of semantic rules in sync. Yeah, I know a system could be devised to handle this automatically, but things tend to go to the lowest common denominator.
3. The foundations of the semantic web such as XML, or its next best thing are only as good as the tags that people define for it. If there isnt a consolidated common understanding of tag meaning, then there is no point in defining a highly extensible base language.
4. End users wont trust the applications... privacy issues, not enough reason to break their existing schemas, would rather just do things themselves.
I agree, if psudo-code is detailed enough to describe software, then it isn't psudo-code... it's just code written in some language of the author's choosing. Psudo-code hides software concepts in little black boxes for the sake of saving lines on paper. That's a no-no if you are truly trying to describe software's functionality.
Ok, here's an idea I haven't seen floated around on Slashdot much... Use the closed-source model as a weapon against itself. Corporate software vendors are bound by their own dogma and/or investors to never let their source code out.
Patents REQUIRE full disclosure. Think of a 19th century inventor like Edison. He has to fully describe his invention in a patent disclosure so that anyone in the field can make use of the invention. That is the spirit of a patent. It is required, or the patent is invalid.
Fast forward to the 21st century. If a patent holder cannot fully disclose a working model and description of an invention (i.e. source code.), then the patent holder has violated the responsibilities of a patent holder and looses rights to the patent. Yes there are examples of this, and yes it is clearly spelled out in law.
There are probably concepts that don't require source code to demonstrate, but most code-level innovations that geeks are worried about do. Furthermore, court action brings the possibility that source code could become exposed as evidence - something many companies may greatly fear. A company might not mind leaking some demo code for a single patent. But with a whole arsenal of patents, the burden starts to fall on the patent holder.
This isn't a totally bullet-proof defense, but one worth exploring.
I agree with the orignal post: HTTP has evolved very little when advances there could have had huge benefits. I've also had the idea that pre-sending checksums of images and files could make caching systems vastly more efficient. Browsers wouldn't have to guess when a file needs to be reloaded. (I suspect this is how certain dial-up accelerators offered by some ISPs work.) Some other pretty good ideas were mentioned there too.
However, CSS is the greatest thing to ever happen to the web. If used properly, it provides a seemless way to modify style that is orthogonal to HTML itself....meaning you can have plain old HTML, and it works fine. Want to change the way that HTML renders? great, just change the style sheet for it, or provide alternate styles depending on the rendering device.
I get unnerved that every 3 years, a new web design paradigm comes out that keeps trying to separate content from structure. First it was certain types of HTML tags that were considered 'proper'. Then XML came along and was supposed to be the 'correct' way to do things because it was supposed to focus on content and unify the SGML/HTML/XML schema (which is really meaningless since HTML is fine for its very specific purpose). And now the 'semantic web'. I dont think the problem is with the systems we use, but human nature itself. People tend to put things in written form in concrete ways, they don't want, or don't have the disipline to separate the content from the presentation.
Non-technical people understand the power of the web as it is today. It is popular because it was already a great idea. No need to keep re-inventing it.
A patent attorney would say:
patent defenses a patent must be enforced within a reasonable amount of time that infringement is known, and there must be an intended use claimed by the patent.
Kodak certainly is pretty late in enforcing its patent, and I think its unlikely that they have a practical use either.
It seems to me that the reason Sun couldn't settle before going to trial is that there is nothing to settle here. Kodak is just wasting everyone's time and money.
The article didn't seem to cover this issue. But I've been following this for a while.
The reason such a weapon is desirable (or feared) isn't the size of the explosion, but the fact that Hf-isomer weapons can be made to cover the middle ground between conventional and nuclear weapons. An army equipped with such weapons is tactically superior to an army with only conventional explosives. Imagine grenades that can level an entire city block. SAM missiles could knock out an entire squadron of planes at a time. Large ships could easily be sunk by a very small cruise missile or torpedo.
Even if the conventional army has a nuclear deterrent, it will not deter the use of isomer weapons.
Spreadsheets happen all to often. Then you get like 17 different lists floating around the office with highly redundant, but ever so slightly orthogonal data... with no revision control, and no common process.
I myself am guilty of this as well..because it is often the fastest way to just play around in a spreadsheet. But you should always stop and work with the IT staff to see if a better solution can be found.
From a coding perspective, I don't see a huge advatage to be gained by throwing away class definitions and using existing objects instead. In both cases you (hopefully) get a fresh copy of an object with all values set to a known/sane state.
But I have to say that inhereting from an existing object as prothon does is really bad from a design and maintainablility standpoint. Its hard to follow exactly what properties a given instance will have at a given time. What if objects are created dynamically (as most sophisticated programs would do). Now at run-time, we can't count on exactly what state the parent object will be in... what if a member function or variable was deleted or over-ridden, now any children spawned will be broken.
There is an important motivation to have inheritance from instances though. This could allow for modeling real-world data such as business rules which don't fit well into traditional data structures like tables or trees. I'm intereested in designing a system that does this by modeling differences and similarities between concepts simulataneously. However, I wouldn't do it as a programming language, but as a data storage model to be implemented in Python. The idea is to have data structures that can implement successively more specific instances of nodes, and abstract groups of nodes to better model structures needed for AI problems.
Slashdot Mirror
Exactly.
/. looking for technical talent because of the low signal to noise ratio.
Even more to the point... You don't find and/or exploit 'MBA' types. They come find you and exploit you. That is their nature - they have the drive, the ability to control people, and the willingness to take risk and stay on the ball. If you want to focus on your technical and operational interests, that is fine, but you will play second fiddle to those that assume command. Likewise, there is nothing unethical about said people who maintain control. That is just human nature's way of creating a productive society. PHB's have more value than a lot of geeks admit, even if they are boneheaded about anything technical or intellectual.
On the flip side, I wouldn't spend too much time on
The first point is debatable.
Can you back up your assertion that silver-backed currency is superior, in contrast to the fact that all major economies/ nations use a fiat-currency? Despite the faults of backed currency, how is it still better??? The only arguable point is that is helps to keep inflation low, but that isn't guaranteed, and there are more problems than benefits like I mentioned. Other problems that it causes are trade imbalances and limited money supply (think required reserve ratio or the lack of).
The major complaint with fiat-money is that it can lead to inflation because the supply is state-controlled. That is true for nations without sound fiscal policy. The Dollar is strong and so widely used in foreign markets due to the US's commitment to sound policy (though you may disagree on political grounds if you are a Libertarian, the policy is sound.)
Dual currency is a huge problem. It's bad enough when I get slipped a Canadian quarter that I can't put it a vending machine. I know 'Liberty Dollars' claim to be redeemable in '95% of stores'. I flat-out don't believe that, and would be fearful of converting my money to a largely unrecognized system. Do you really want every cashier to be an expert on every possible currency in circulation??
Interesting. But unfortunately, the proponents of this missed too many economic classes to understand why its a bad idea. It's not inflation proof just because it's backed by some arbitrary precious good. In fact that creates more harm than good, which is why the US gave up on the Silver/Gold Standards. I.e. if someone finds new lodes of gold then your monetary value goes to hell.
You will have liquidity issues as well, which is what money is supposed to prevent in the first place. That means that people will experience barriers to trade when they have to find a common currency to use. It's like trying to get a bunch of Linux geeks to agree on a common distribution. The Fed keeps this to a minimum by forcing us to use one common currency.
Also, if I'm not mistaken, it's unconstitutional in the US to have arbitrary monetary systems besides the dollar.
Like this one
Don't forget Econ 101. Alternates and substitutes have as much effect on price. i.e. the cost of building Linux from the ground-up, or using a substitute BSD-liscensed product. like.. oh.. say.. BSD.
This while thing looks shady though.. A post on some board for a $50K deal?
Exactly, as a contractor you will still have a boss (either your customers or yourself) that you have to answer to. This means that you won't get paid to do whatever you want to do. You need to have the discipline to understand and execute your customer's requirements.
If you are just looking for a creative outlet to express yourself, get a regular job doing whatever you can. Do what you love on your time as a hobby, and for your own education. You will be happier with this situation, because nothing takes the fun out of programming faster than having to make money at it.
If you are very good, have a big professional network, and 20 years of experience, then you might make more than you would working for someone else. As much as you think your boss is clueless (my employment experience is no exception), having a company to work within adds much economic value that you can't provide directly to your customers if you were independant.
I agree with you, but good process doesn't bore me at all. But I know I'm the exception. The truth is Managagment just wants to get the job done with the least resources, so they pressure the techs with increasing workload and tend to look the other way when people cut corners to get the job done. Techs know they are supposed to do process 100%, but they don't want to be the guy who takes twice as long to do stuff because of following procss. So whenever I see major screw ups like this, I blame management and ops equally.
Engineers, BTW, write processes but never follow their own process. Thus, they leave messes for the techs to sort out.
That's not how a software firewall is supposed to work. Either Microsoft doesn't get it, or they are trying to dumb it down so the average user feels like they are protected, but really aren't.
Software firewalls can either block outgoing connections from spyware or untrusted apps to keep data leaking out of your machine from within. Just get Zonealarm or equivalent, and your problems are solved. Programs must ask for permission before accessing the network. MS firewall didn't ever seem to do this when I tried it. Software firewalls can also actively filter content coming and going through known connections like HTTP. But this isn't as foolproof.
Microsoft's firewall, in my experience, does nothing except take you machine off the network. Big deal I can get the same effect by unplugging my ethernet cable, thank you.
To make a firewall that 'keeps people from breaking into my machine' is asinine. If you don't want someone accessing a service, you turn it off or change it's configuration to deny specific external hosts. If there are holes in the OS that a hacker can exploit, then a firewall is only a band-aid, that may or may not work. And it isn't any help if you actually intend to run services on you machine.
good points, and they help to demonstrate the trade-offs in transitioning to superconductors. The main issue is that superconductivity isn't a slam dunk, and it doesn't equal 100% efficiency. I think the article was just too rosy saying how revolutionary superconductors will be. The diminising returns of 1% efficiency improvment (claimed in the article) and smaller motors on a large ship may not justify the high maintainance and design costs of a superconducting system. I'd like to see how much plumbing and equipment is needed to provide ongoing cryogenic cooling.
After reading the arcticle, the reason why these motors can achieve higher density is because the thermal dissapation issues are reduced when you don't have DC losses in your coil windings.
You are right as far as lower freqencies needing more core material. But, I can't see how superconductors would change that equation at all. Even if the superconductor carries more current, the magnetic material has the same basic flux energy storage capacity. Ships tend to use higher frequencies anyway, such as 400Hz, so frequency probably isn't the problem. In a propulsion system, the design engineers are probably allowed to choose any frequency they want. Also, superconductors don't eliminate all loses. Core losses are still going to be an issue unless the motor design is significantly different than anything seen before, or uses superconducting mu-metal.
You can always make a slower, higher torque high-frequency direct-drive sync motor by adding more poles. But you can't make a low-freq motor faster. i.e. top speed for a 2-pole 60Hz sync motor is 3600 RPM.
Also, from what I remember, superconductors tend to lose superconductivity in strong magnetic fields. Hopefully, they have worked around that problem.
exactly. There is a matrix of capacitors with only drive cicuits (transistors) at the end of the rows and columns. That is basically why computer designs always go with the relatively slow DRAM for mass memory due to its compact and economical nature. If you are designing a system that needs speed (like a cache or video device) you will always go with SRAM. But exect to pay _hundreds_ of times more per MB, and expect to have a way more physical address lines to contend with.
Also, answering some of the other posts above, DRAM with bad cells will get downgraded by chopping off rows containing bad cells. So you might take a 32Mx32 chip and make it 32Mx16. Depending on the nature of the defects, the chip might be downgraded for non-critical use in things like digital answering machines which can tolerate a few bad bits in the data stream. I dont think downgrading the speed helps much though as far as bad individual bits.
It is actually way easier to make hydrogen fuel via electrolosis than it is to make an efficient and practical fuel cell.
All you need is some water with electrolyte. NaOH works the best because, unlike NaCl, it won't outgas anything except pure hydrogen and oxygen. Common salt will outgass poisonous levels of chlorine gas, so don't even try it. Then you just need a DC current of low voltage, and some inert electrodes (graphite rods work great). Hydrogen (H2) gas collects at one of the electrodes (I'll let you do the half-cell equation to figure out which.) Then just deal with some physical issues like collecting the H2 gas SAFELY.
The problem is that you often don't know how much buffer a function call will require. If a function expects a buffer to be passed in (as a reference), then it is essentially a fixed buffer whether you created it using myBuff[100] or malloc(100*sizeof(someDataType)). That is often the problem C programmers face and there isnt a good solution if the code you are forced to use is crappily designed.
The correct ways of handing off a buffer are one of the following:
1.) dont use crappy function calls like the above for any reason. If that is what was handed to you, complain.
2.) In C++, use a CString, assuming the function you are calling supports it.
3.) Only use function calls that support a counted buffer of some type:
a.) Some function calls expect to be called twice, or have a helper function - once to get the exact buffer length, then again (once you have created that buffer) to fill it.
b.) only use the strn versions of a function, where You specifiy the length of the buffer.
c.) You could pass in a null terminated buffer, but only if the buffer would never contain a zero other than the terminator, and that you know that the function you call will check for that terminator, and never over-run it. Best to avoid this. This function would also have to somehow tell you that it needs to be called again to get any remaining data.
But the parent is correct: Buffer overflows are caused by lazy coders. Coders who assume that an input will be of a certain length, or 'should probably never be longer than this big number I just picked' are crappy programmers, and are not worth their salt. It is tedious to write code properly, and requires disipline, review, and testing. Not something most managers want to deal with either.
Bingo.
And I would only consider complexity of a solution to be that which cannot be abstracted or factored out to underlying functions and glue code.
Here is a bit of trivia you'll be able to answer then... what does TNT stand for? I'll give you a hint, it doesn't stand for Tri-Nitro Dynamite.
Like all things, the answer is someplace in the middle. This article was way too Utopian. OTOH, saying that privatization is all bad is wrong also.
A agree with what you said, if we could do what the article states with re-using spectrum, then there wouldn't be any argument at all. The reality is that there are a few tricks to multiplex the spectrum, but it's still finite. You can do things like directional antennas, and digital spread spectrum can co-exist with modulated transmission. But, the work of Shannon and Nyquist put very hard limits on the maximum throughput of a channel with real-world noise. The analogy that the human ear can pick one conversation out of n-others simply isn't true. The author hasn't, apparently, been to a party where you keep having to say: 'huh?', 'what?'. Add more background conversations/noise (Shannon) and the throughput falls off. I can sort of see how you could discriminate 'conversations' with the right protocols, but the idea that it is infinite is very bad science. I believe the human ear works very similar to spread spectrum technology, but also draws from syllable information stored in the mind's knowledge base to discriminate conversations. The point is that it isn't a miracle, and still has physical limits.
There is definitely much wasted spectrum because the government has put it out of reach of any economic pressures. But there needs to be some central control because the invisible hand of the economy isn't intelligent enough to correctly plan certain aspects of spectrum allocation. Also, interactivity of devices requires some authoritarian control even if it isn't 100% efficient. Set aside spectrum for military and public services. Let the rest be traded and sold commercially. The FCC should still be involved in the facilitation of these transactions for 2 reasons. 1. its the equivalent of keeping public deeds on property - there needs to be an authoritative unbiased record stored someplace. 2. There will be times that proposals need to be rejected because of technical incompatibilities. The 2 parties in a transaction may not care about an issue that would effect a third party.
I don't think spectrum fragmentation will be a problem at all. There will be strong economic pressure to keep chunks of spectrum together. There will be capitalists who act as consolidators if there is value in having unfragmented spectrum.
I totally agree, I was going to post the same idea. AI research has been tripping and falling down over the same damn problem for half a century because computer scientists in that area cannot see the futility of the symbolic approach. (The semantic web is a very structured approach to ill defined human/real-world data.) I thought research of the 1990's finally put the nail in the coffin with 'fuzzy' approaches such as neural nets et. al.
Even if the semantic web was technically viable (it isn't), the human factors would kill it:
1. Major tech companies will corrupt and pervert the standards and intended usage.
2. Overworked and underskilled web page designers will write broken semantic 'code' because they just want the page to look a certain way. They won't care about keeping a parallel set of semantic rules in sync. Yeah, I know a system could be devised to handle this automatically, but things tend to go to the lowest common denominator.
3. The foundations of the semantic web such as XML, or its next best thing are only as good as the tags that people define for it. If there isnt a consolidated common understanding of tag meaning, then there is no point in defining a highly extensible base language.
4. End users wont trust the applications... privacy issues, not enough reason to break their existing schemas, would rather just do things themselves.
I agree, if psudo-code is detailed enough to describe software, then it isn't psudo-code... it's just code written in some language of the author's choosing. Psudo-code hides software concepts in little black boxes for the sake of saving lines on paper. That's a no-no if you are truly trying to describe software's functionality.
Ok, here's an idea I haven't seen floated around on Slashdot much... Use the closed-source model as a weapon against itself. Corporate software vendors are bound by their own dogma and/or investors to never let their source code out.
Patents REQUIRE full disclosure. Think of a 19th century inventor like Edison. He has to fully describe his invention in a patent disclosure so that anyone in the field can make use of the invention. That is the spirit of a patent. It is required, or the patent is invalid.
Fast forward to the 21st century. If a patent holder cannot fully disclose a working model and description of an invention (i.e. source code.), then the patent holder has violated the responsibilities of a patent holder and looses rights to the patent. Yes there are examples of this, and yes it is clearly spelled out in law.
There are probably concepts that don't require source code to demonstrate, but most code-level innovations that geeks are worried about do. Furthermore, court action brings the possibility that source code could become exposed as evidence - something many companies may greatly fear. A company might not mind leaking some demo code for a single patent. But with a whole arsenal of patents, the burden starts to fall on the patent holder.
This isn't a totally bullet-proof defense, but one worth exploring.
However, CSS is the greatest thing to ever happen to the web. If used properly, it provides a seemless way to modify style that is orthogonal to HTML itself. ...meaning you can have plain old HTML, and it works fine. Want to change the way that HTML renders? great, just change the style sheet for it, or provide alternate styles depending on the rendering device.
I get unnerved that every 3 years, a new web design paradigm comes out that keeps trying to separate content from structure. First it was certain types of HTML tags that were considered 'proper'. Then XML came along and was supposed to be the 'correct' way to do things because it was supposed to focus on content and unify the SGML/HTML/XML schema (which is really meaningless since HTML is fine for its very specific purpose). And now the 'semantic web'. I dont think the problem is with the systems we use, but human nature itself. People tend to put things in written form in concrete ways, they don't want, or don't have the disipline to separate the content from the presentation.
Non-technical people understand the power of the web as it is today. It is popular because it was already a great idea. No need to keep re-inventing it.
me too, I've thought about it too
too bad everything is twice as far away, and you have to wait X years to get the images.
A patent attorney would say: patent defenses a patent must be enforced within a reasonable amount of time that infringement is known, and there must be an intended use claimed by the patent.
Kodak certainly is pretty late in enforcing its patent, and I think its unlikely that they have a practical use either.
It seems to me that the reason Sun couldn't settle before going to trial is that there is nothing to settle here. Kodak is just wasting everyone's time and money.
The article didn't seem to cover this issue. But I've been following this for a while.
The reason such a weapon is desirable (or feared) isn't the size of the explosion, but the fact that Hf-isomer weapons can be made to cover the middle ground between conventional and nuclear weapons. An army equipped with such weapons is tactically superior to an army with only conventional explosives. Imagine grenades that can level an entire city block. SAM missiles could knock out an entire squadron of planes at a time. Large ships could easily be sunk by a very small cruise missile or torpedo.
Even if the conventional army has a nuclear deterrent, it will not deter the use of isomer weapons.
Spreadsheets happen all to often. Then you get like 17 different lists floating around the office with highly redundant, but ever so slightly orthogonal data... with no revision control, and no common process.
..because it is often the fastest way to just play around in a spreadsheet. But you should always stop and work with the IT staff to see if a better solution can be found.
I myself am guilty of this as well
From a coding perspective, I don't see a huge advatage to be gained by throwing away class definitions and using existing objects instead. In both cases you (hopefully) get a fresh copy of an object with all values set to a known/sane state.
But I have to say that inhereting from an existing object as prothon does is really bad from a design and maintainablility standpoint. Its hard to follow exactly what properties a given instance will have at a given time. What if objects are created dynamically (as most sophisticated programs would do). Now at run-time, we can't count on exactly what state the parent object will be in... what if a member function or variable was deleted or over-ridden, now any children spawned will be broken.
There is an important motivation to have inheritance from instances though. This could allow for modeling real-world data such as business rules which don't fit well into traditional data structures like tables or trees. I'm intereested in designing a system that does this by modeling differences and similarities between concepts simulataneously. However, I wouldn't do it as a programming language, but as a data storage model to be implemented in Python. The idea is to have data structures that can implement successively more specific instances of nodes, and abstract groups of nodes to better model structures needed for AI problems.