I'm getting sick of this crap "journalism". if you want to make a comment, add a comment. Don't add your opinion to the summary. Just report the facts. If you really have to, blog about your opinion and add a link to that blog, stating that it's your opinion.
You must be new here. The summary of an article is nearly always the *opinion* of whoever submitted it. The "news" part is in the original source to which the link(s) in the summary point (assuming the original source isn't itself just an opinion or troll). The summary IS the "blog" part, and it acts as the root of the entire discussion thread. That's the way it has always worked on this site, and it's not very hard to figure out.
The meaning of ambiguous parts of the Constitution is decided by the Supreme Court. The current majority of that institution says that they interpret the Constitution based on the "original intent" of its authors. Clearly, the authors did not originally mean 5000 years, nor any other absurd number that my old calculus professor would have called "large, but finite". So such numbers are irrelevant.
I've never heard a convincing argument why Mickey Mouse should be taken away from them if he's still a viable property.
The US Constitution, the highest law of the land, specifically states that copyright terms are to be limited. Whether it convinces you or not is irrelevant.
Re:metaprogramming FTW!
on
Land of Lisp
·
· Score: 1
Balkanize –verb (used with object), -ized, -izing.
1. to divide (a country, territory, etc.) into small, quarrelsome, ineffectual states.
2. ( often lowercase ) to divide (groups, areas, etc.) into contending and usually ineffectual factions: a movement to balkanize minority voters.
Re:metaprogramming FTW!
on
Land of Lisp
·
· Score: 1
What I want to know is why, in 2010, most commonly used languages (Java, C++, C#, etc) do not have even a tiny fraction of the metaprogramming ability that LISP provided to us many decades ago.
Because metaprogramming is confusing. For example, it allows and encourages every developer to come up with his own personal class system, templating system, and collections framework, along with their own custom language keywords to define novel control constructs. Of course each personal framework is incompatible with anybody else's personal framework. This kind of balkanization has been the story of Lisp ever since it was invented.
The pebbles are made mainly out of graphite, a substance which can burn when exposed to oxygen.
A high-explosive charge detonated in the reactor core would create a shock wave that could potentially fracture the ceramic containment layers and fuel seeds in the pebbles, freeing the flammable graphite and fission products into the environment. A kinetic kill anti-tank projectile would probably have a similar effect.
More than six decades ago, the British had the bombs that could penetrate several meters of reinforced concrete. The US has had small missiles that can do the same thing with pinpoint accuracy for a long time. This really isn't rocket science any more. Even developing countries could potentially put together a weapon that could take out these reactors and create a real mess out of our forward bases.
No, like I said, the GPL always gives you the freedom to NOT use their code if you don't like their terms. This is likely the exact same extent of freedom that you want to give to your users, and it is not coercion, so it is not "communist".
You have myopia, selfishly looking at only one incremental step of the whole process, and ignoring what happens as a consequence.
If you publish under more a restrictive licence, then *I* have no longer have any options to republish. You've restricted *my* freedom, and the freedom of everyone else in the world. Your fork becomes a dead end (and possibly a trap luring people into vendor lock-in).
Your dead end allows nobody else to increase their freedom beyond the standard sheepish "if you don't like the license, don't use the program". Well, you already have that particular freedom when you consider whether or not to incorporate GPLed code in the first place. The GPL gives you at least as much freedom as you seem to be willing to give anyone else.
But *I* would want you to do that, so that I could improve it further if need be. So with respect to your proposed modifications, it's more free for myself and the other 6,999,999,999 people on this planet who aren't you.
MythTV added a feature a while back to work around this issue. IIRC, they now keep a handle open to video files while they delete them. This causes the kernel to not actually do the delete, then over a span of about 10 minutes MythTV repeatedly shaves chunks off the end using truncate() until the file reaches 0 bytes.
Prior to this, the system could get really bogged down right after deleting shows. I was careful not to delete too many shows at once; I had actually seen the back end lock up after telling it to delete a bunch of shows.
Haha. You provided only four lines of code, and look what we get:
$ gcc t.cpp t.cpp:1:9: error: #include expects "FILENAME" or <FILENAME> t.cpp: In function 'int main()': t.cpp:4: error: 'cout' is not a member of 'std' t.cpp:4: error: expected ';' before string constant
At that rate, a large software product developed like this would have millions of bugs.
As far as I know, efficiencies that high are only possible in a combined cycle application where you also add a huge steam turbine powered by the exhaust heat of the gas turbine. The gas turbine by itself is not as efficient as a good diesel engine, and gas turbine efficiency scales with size. By definition, an automotive turbine is going to be small and inefficient.
You don't seem to have any idea of how much total energy this nation consumes vs. how much is in the food we eat. The US uses somewhere in the neighborhood of 1e20 joules of energy each year. If the average person consumes 2500 Cal per day of food, that's about 1.1e18 J of food energy per year.
We use almost 100 times as much total energy as the amount of energy in the food we currently grow. Even supplying the small fraction of energy that goes into automobile transportation is not going to be possible by increasing production of food crops, especially since irrigation water is already in seriously short supply in many areas.
Of course many inventions do after they're invented...
Things that seem obvious after they've been invented should not be patentable in the first place. Such innovations would probably be stumbled upon by someone else in short order. Putting a 20-year monopoly on such ideas is counterproductive to the economy, partly because lots of others tend to casually implement the feature. They independently discover it and use without much thought, because it seems obvious. That sets up a rich playfield for patent trolls.
There are plenty of inventions that *don't* seem obvious even after you see how they work (for example, the Rubik's cube). Patents should be reserved only for those cases.
Isnt it simpler to ise the arrow keys for navigation and backspace for backspace,etc.. I believe gedit does the same for Linux
Pls enlighten me..
Firstly, the arrow keys work just fine in vim. However, in my experience, the arrow keys are just about the worst irritant for RSI problems, surpassed only by certain mouse operations. The arrow keys encourage you to bend your wrist sharply and make a bunch of repeated keypresses. This is very hard on the tendons that go through the wrist.
Using the HJKL keys in vim is much more natural hand positioning, and the powerful cursor movement commands in vim cut way down on how many keys need to be pressed in the first place. (I do map the ESC key in vim to Alt+F so that I don't have to reach for that all the time either.)
Don't think of it as 1920x1080. Think of it as two 960x1080 areas.
I almost always split my editor into two vertical panes, so I already use my 1600x1200 4:3 monitor as two 800x1200 areas. That's still more useful than 960x1080 areas. (Even with this, I keep the desktop taskbar on the right side and hide the editor's toolbars and menu bars to eke out vertical space for a few more precious rows of text.)
It looks like I might have to cling to this monitor forever, like people had to do with the old IBM Model M keyboards.
Your only valid point is about the flexible fuel (and even that is mitigated by having to transport much less diesel in the first place).
All the other operations wouldn't take place at forward bases, so the energy cost is orders of magnitude less than guzzling gas on the battlefield. I saw the Discovery Channel show about the facility that does major overhauls on the M1; it's done right here in the USA.
the US Army Corps of Engineers has been developing the logistics and technology to have supply convoys go overland
Another benefit of this approach is that you could probably get the History Channel to help fund it so they could turn it into one of their annoying reality shows.
An example would be to implement a binary full adder. (Babbage used straight decimal operations on his gears, but I remember seeing somewhere that he was at least aware of binary logic.)
I haven't really put that much thought into it, but I could imagine having 2 master actuators that act like "clocks" over the whole machine. A full adder might have three plates or levers shaped so that each input can pull it into a certain position. The first master clock would actuate a logic operation, shifting two output mechanisms based on the adder function and the three inputs. The second master clock would cause the outputs to pull on strings or wires and transfer the result to the next adder. The net result would be a bit-serial adder, computing one bit for each pair of clock transitions. (In a difference engine, all the adders might naturally pipeline together neatly for efficiency.)
What I sometimes wonder in hindsight, is could Babbage's machines have been built with the technologies of the time using different techniques that would have been more easy to achieve. He was always pushing the envelope of machining technology with axles and gears, partly in an effort to gain speed. (For example, in the difference engine the gear system had a very complex look-ahead carry feature to make it much faster.) The machines required very tight tolerances and a good deal of force to operate.
Gears work mostly on compressive forces. If instead he had built a machine based mostly on tension, like pulling strings wrapped around wheels and cogs, would the machines have been more practical to build? The machines might have been one or two orders of magnitude slower. However, the problems he was after, like computing logarithm tables, are highly parallelizable. Instead of trying to create one super machine (and never succeeding), would he have been better off with making a bunch of much slower, easier to build machines?
Slashdot Mirror
I'm getting sick of this crap "journalism". if you want to make a comment, add a comment. Don't add your opinion to the summary. Just report the facts. If you really have to, blog about your opinion and add a link to that blog, stating that it's your opinion.
You must be new here. The summary of an article is nearly always the *opinion* of whoever submitted it. The "news" part is in the original source to which the link(s) in the summary point (assuming the original source isn't itself just an opinion or troll). The summary IS the "blog" part, and it acts as the root of the entire discussion thread. That's the way it has always worked on this site, and it's not very hard to figure out.
The meaning of ambiguous parts of the Constitution is decided by the Supreme Court. The current majority of that institution says that they interpret the Constitution based on the "original intent" of its authors. Clearly, the authors did not originally mean 5000 years, nor any other absurd number that my old calculus professor would have called "large, but finite". So such numbers are irrelevant.
I've never heard a convincing argument why Mickey Mouse should be taken away from them if he's still a viable property.
The US Constitution, the highest law of the land, specifically states that copyright terms are to be limited. Whether it convinces you or not is irrelevant.
Balkanize
–verb (used with object), -ized, -izing.
1. to divide (a country, territory, etc.) into small, quarrelsome, ineffectual states.
2. ( often lowercase ) to divide (groups, areas, etc.) into contending and usually ineffectual factions: a movement to balkanize minority voters.
What I want to know is why, in 2010, most commonly used languages (Java, C++, C#, etc) do not have even a tiny fraction of the metaprogramming ability that LISP provided to us many decades ago.
Because metaprogramming is confusing. For example, it allows and encourages every developer to come up with his own personal class system, templating system, and collections framework, along with their own custom language keywords to define novel control constructs. Of course each personal framework is incompatible with anybody else's personal framework. This kind of balkanization has been the story of Lisp ever since it was invented.
The pebbles are made mainly out of graphite, a substance which can burn when exposed to oxygen.
A high-explosive charge detonated in the reactor core would create a shock wave that could potentially fracture the ceramic containment layers and fuel seeds in the pebbles, freeing the flammable graphite and fission products into the environment. A kinetic kill anti-tank projectile would probably have a similar effect.
More than six decades ago, the British had the bombs that could penetrate several meters of reinforced concrete. The US has had small missiles that can do the same thing with pinpoint accuracy for a long time. This really isn't rocket science any more. Even developing countries could potentially put together a weapon that could take out these reactors and create a real mess out of our forward bases.
No, like I said, the GPL always gives you the freedom to NOT use their code if you don't like their terms. This is likely the exact same extent of freedom that you want to give to your users, and it is not coercion, so it is not "communist".
You have myopia, selfishly looking at only one incremental step of the whole process, and ignoring what happens as a consequence.
If you publish under more a restrictive licence, then *I* have no longer have any options to republish. You've restricted *my* freedom, and the freedom of everyone else in the world. Your fork becomes a dead end (and possibly a trap luring people into vendor lock-in).
Your dead end allows nobody else to increase their freedom beyond the standard sheepish "if you don't like the license, don't use the program". Well, you already have that particular freedom when you consider whether or not to incorporate GPLed code in the first place. The GPL gives you at least as much freedom as you seem to be willing to give anyone else.
I may not want to do that.
But *I* would want you to do that, so that I could improve it further if need be. So with respect to your proposed modifications, it's more free for myself and the other 6,999,999,999 people on this planet who aren't you.
Make them learn stuff, damage their brains and try teaching them new stuff.
My friends and I survived that very experiment back in my college days. We used the "weekly drink special" methodology.
MythTV added a feature a while back to work around this issue. IIRC, they now keep a handle open to video files while they delete them. This causes the kernel to not actually do the delete, then over a span of about 10 minutes MythTV repeatedly shaves chunks off the end using truncate() until the file reaches 0 bytes.
Prior to this, the system could get really bogged down right after deleting shows. I was careful not to delete too many shows at once; I had actually seen the back end lock up after telling it to delete a bunch of shows.
It has a pro video subsystem, a pro audio subsystem, a pro graphics subsystem, a pro Web development subsystem
You sound just like a cheesy salesman in an overpriced stereo store at the local mall.
I bet that Macs exclusively use 50-mil oxygen-free copper in their circuit boards, too.
Haha. You provided only four lines of code, and look what we get:
At that rate, a large software product developed like this would have millions of bugs.
I really start to get scared when a developer releases an update to a product and starts off by declaring that there are "hundreds of bug fixes".
Can you name even a single large software product (other than ultra-expensive avionics) that provably doesn't have hundreds of bugs?
With desktops, they may not be able answer emails, but they could at least still use office and get something accomplished if the network went down.
Or in some cases, they'd have to switch from networking on Facebook to locally running Minesweeper.
Gas turbines have are over 60% efficient.
As far as I know, efficiencies that high are only possible in a combined cycle application where you also add a huge steam turbine powered by the exhaust heat of the gas turbine. The gas turbine by itself is not as efficient as a good diesel engine, and gas turbine efficiency scales with size. By definition, an automotive turbine is going to be small and inefficient.
You don't seem to have any idea of how much total energy this nation consumes vs. how much is in the food we eat. The US uses somewhere in the neighborhood of 1e20 joules of energy each year. If the average person consumes 2500 Cal per day of food, that's about 1.1e18 J of food energy per year.
We use almost 100 times as much total energy as the amount of energy in the food we currently grow. Even supplying the small fraction of energy that goes into automobile transportation is not going to be possible by increasing production of food crops, especially since irrigation water is already in seriously short supply in many areas.
Of course many inventions do after they're invented...
Things that seem obvious after they've been invented should not be patentable in the first place. Such innovations would probably be stumbled upon by someone else in short order. Putting a 20-year monopoly on such ideas is counterproductive to the economy, partly because lots of others tend to casually implement the feature. They independently discover it and use without much thought, because it seems obvious. That sets up a rich playfield for patent trolls.
There are plenty of inventions that *don't* seem obvious even after you see how they work (for example, the Rubik's cube). Patents should be reserved only for those cases.
Every ubuntu release is announced here. Even RC ones. Why? Other operating systems and distributions are not.
Not true. Announcements are also posted here for every minor tweak to BeOS and AmigaOS.
Isnt it simpler to ise the arrow keys for navigation and backspace for backspace,etc..
I believe gedit does the same for Linux
Pls enlighten me..
Firstly, the arrow keys work just fine in vim. However, in my experience, the arrow keys are just about the worst irritant for RSI problems, surpassed only by certain mouse operations. The arrow keys encourage you to bend your wrist sharply and make a bunch of repeated keypresses. This is very hard on the tendons that go through the wrist.
Using the HJKL keys in vim is much more natural hand positioning, and the powerful cursor movement commands in vim cut way down on how many keys need to be pressed in the first place. (I do map the ESC key in vim to Alt+F so that I don't have to reach for that all the time either.)
Don't think of it as 1920x1080. Think of it as two 960x1080 areas.
I almost always split my editor into two vertical panes, so I already use my 1600x1200 4:3 monitor as two 800x1200 areas. That's still more useful than 960x1080 areas. (Even with this, I keep the desktop taskbar on the right side and hide the editor's toolbars and menu bars to eke out vertical space for a few more precious rows of text.)
It looks like I might have to cling to this monitor forever, like people had to do with the old IBM Model M keyboards.
Your only valid point is about the flexible fuel (and even that is mitigated by having to transport much less diesel in the first place).
All the other operations wouldn't take place at forward bases, so the energy cost is orders of magnitude less than guzzling gas on the battlefield. I saw the Discovery Channel show about the facility that does major overhauls on the M1; it's done right here in the USA.
the US Army Corps of Engineers has been developing the logistics and technology to have supply convoys go overland
Another benefit of this approach is that you could probably get the History Channel to help fund it so they could turn it into one of their annoying reality shows.
An example would be to implement a binary full adder. (Babbage used straight decimal operations on his gears, but I remember seeing somewhere that he was at least aware of binary logic.)
I haven't really put that much thought into it, but I could imagine having 2 master actuators that act like "clocks" over the whole machine. A full adder might have three plates or levers shaped so that each input can pull it into a certain position. The first master clock would actuate a logic operation, shifting two output mechanisms based on the adder function and the three inputs. The second master clock would cause the outputs to pull on strings or wires and transfer the result to the next adder. The net result would be a bit-serial adder, computing one bit for each pair of clock transitions. (In a difference engine, all the adders might naturally pipeline together neatly for efficiency.)
What I sometimes wonder in hindsight, is could Babbage's machines have been built with the technologies of the time using different techniques that would have been more easy to achieve. He was always pushing the envelope of machining technology with axles and gears, partly in an effort to gain speed. (For example, in the difference engine the gear system had a very complex look-ahead carry feature to make it much faster.) The machines required very tight tolerances and a good deal of force to operate.
Gears work mostly on compressive forces. If instead he had built a machine based mostly on tension, like pulling strings wrapped around wheels and cogs, would the machines have been more practical to build? The machines might have been one or two orders of magnitude slower. However, the problems he was after, like computing logarithm tables, are highly parallelizable. Instead of trying to create one super machine (and never succeeding), would he have been better off with making a bunch of much slower, easier to build machines?