Compression CANNOT guarantee anything better than 1:1 ratio - it is ENTIRELY dependent on the data.
Precisely what I was going to say. But then I started thinking about it some more. You can't guarantee even a 1:1 ratio; purely random data will compress to slightly larger than original size, as you have to tag it.
Stepping back for a second, though, is this REALLY a problem for most systems? I'd be willing to bet that 99.999% of the time, multi-user systems run memory images that are at least moderately compressable. The curve of pessimistic memory availability vs. actual usage would yield something akin to a MTBF, which would be a good enough guarantee for those server spaces that are looking to save a few bucks.
Of course, memory usage limits would need to be in place to prevent some really obvious machine-crash attacks from users, but isn't that true already?
Page says this is what they've paid so far. From the looks of that list, they've got a ways to go.
Interesting start, but they've still got memory, motherboards, and some other stuff to go. That's going to crank the price tag at least a couple thousand dollars...
I develop open source software in my free time. It's not what I'm paid to do. Startups like this are providing opportunities for open source hobbiests to turn the tables and do what they really like to do, not as a hobby on the side of something that pays the bills, but to pay the bills.
Granted, there are some potential pitfalls. Whenever you bring money into the equation, there exists a potential to lose the whole "itch-scratching" motivation in the wake of deadlines and targets. And often, corporations are antithetical to the whole concept of giving away your work for the sake of something bigger.
Look at some of the examples so far, though. Linus Torvalds is working for Transmeta, Alan Cox gets paid by Redhat, Eric Allman founded Sendmail, Miguel started Helix Code, and they're all still churning out the free software.
I see it as encouraging. An undercurrent in the whole open source movement is the recognition that pure greed-based capitalism isn't necessarily the only or best philosophy for life. The key seems to be prioritization; all the people I've mentioned have made giving away the code a higher priority than a paycheck, and, until I see reason not to, I trust them to continue to do so in their new positions.
The ARM arch doesn't have a 64-bit variant, so whatever chip is in there, it ain't ARM-based. 64-bit embedded RISC processor probably means MIPS, but not necessarily...
Having read much that Gwennap has written for Microprocessor Report et. al, I've come to believe that either this guy owns Intel stock -- a LOT of Intel stock -- or he's the journalistic equivalent of the IT managers that say "You don't get fired for buying IBM/M$/whatever.
I can't recall ever seeing anything he's written that says anything other than positively glowing things about Intel. It's almost like he's trying to be the personal antidote to The Register, but whereas the Register is an admittedly biased gossip rag for IT folks, Mr Gwennap is supposed to be an independent analyst.
My point is, take anything he says about Intel with a very large grain of salt.
If someone hacks the internal server, just reboot.
So if someone hacks the internal web server, you reboot, and end up with a machine that's still configured with a security hole? Sounds like a pretty bad idea to me...
Incremental backups nightly. If you're hacked, you find the hole, restore from backup if necessary, and patch the hole!
but really and truly is this not steeling from the web publishers?
It's a power shift, no question. Though in the past it has been possible to block banner ads (Junkbusters has had a proxy server that blocks banner ads for years now) it has been enough of a pain that 99+% of people just aren't going to do it.
Add a menu option on the browser to do the same thing, and you've just made the blocking of banner ads much, MUCH easier for the end user, and lots of people will take advantage of it. I don't think anyone's going to argue against that.
The status quo has created a convenient space for marketers to lurk; they can position ads in such a way that you really have to have them visible in order to see the content you really want. What's key here is the (If you'll pardon the choir preaching on Slashdot...) practical lack of freedom of choice in the viewing of those ads. American society is so infested with advertising and marketing at the moment that the individual who doesn't want to see the pervasive marketing is having his or her freedoms whittled away day by day. It's gotten to the point where people used to the "freebies" provided by advertising question the very morality of providing a way to bypass ads.
It is not immoral to refuse to look at content you don't want to see.
Advertising is lauded as a way to make things free, but from a purely economic view, advertising as we see it today is wasteful in the extreme. Billions of dollars are spent every year to convince you that you need some new good in your life. 99.9% of the time this is pure consumerism hype; someone on the other end of the TV commercial, junk mail, or banner ad is trying to keep their economic niche alive by convincing you to budget money for their product or service that you were just as happy knowing nothing about.
The net result? You have to make more money to afford all the things you now "need". So you work harder, your productivity increases, the economy "grows" and politicians take credit for improving our lives. But is our standard of living really higher? Witness the infomercials that have to spend 15 minutes of a half hour slot trying desperately to convince you that your past advertising-driven purchases were all mistakes because this is the product you really need. There is a schizoprenia implicit to advertising that reveals its true nature.
With respect to banner ads and simple blocking, all that has happened is a power shift away from advertisers and towards end users. If end users are annoyed by ads, they can turn them off. If sites can't survive with users turning off those ads, the sites go down. There is no moral obligation to support that business model. If the cost of that business model is my freedom to choose what I look at, I say that cost is much, MUCH too high.
Pin count - As more integration happens, the reduced pincount of DRDRAM may become a bigger factor. It's a simple matter of 168 vs 55, though the 55 need to be at a higher frequency. It's simply easier to integrate a DRDRAM interface and have enough pins to do all of those other things, like an AGP bus.
The bandwidth/pin count ratio is very important for servers that need huge bandwidth. You can almost put 3 rambus interfaces on a chip for the pin cost of one DDR SDRAM interface. That's something that will make many chip designers take a good hard second look at Rambus
Also, something Tom Pabst never really covered was how much of the Camino performance pitfall was due to the chipset and how much was due to the memory protocol; it's perfectly possible to implement a MUCH more efficient Rambus memory controller than Camino does.
Having said all this, I think Rambus screwed up in many ways; they are notoriously arrogant in the industry, created a product that doesn't yield well, and tried to decommodotize a market, which, although possible, is definitely going against the flow in the industry. But that doesn't mean their technology is uninteresting or that Intel was smoking something when they decided to back Rambus.
DDR SDRAM would have taken a lot longer to come about if JEDEC thought they were sitting pretty with the next generation of mass-produced DRAM.
Bioethics are really going to have to race to keep up with research like this.
So, say you could change something cosmetic about yourself genetically for a reasonable price. For example, what if a virus were available that triggered a whole-body genetic mutation, and the end result was a change in your genetic hair color?
Assuming you wanted that hair color, would you do it? Would the use of genetics for such things be unethical? How sacred is that individual genome that each one of us posseses?
What are the ethical uses of genetic information and modification? To cure disease? To select offspring attributes? There are LOTS of interesting questions that are going to be coming up in the next decade or two.
I'm really wondering about the Microsoft take on it though; it's hardly in keeping with their classic character. They want you to run a MS OS as your primary platform, and leverage that into other areas.
As I see it, allowing VMware to sell preinstalled with a Windows OS in the virtual machine is a threat to the whole primary platform idea. It looks like a way to make it easier for Linux vendors to edge into that primary platform space that they covet so much.
So I'm really wondering what MS sees as their benefit from this deal...
Delphi is allowed. Which is really just Object Pascal with a nice gui maker. Anyway all of the teams I know who placed well at Regionals used pascal. It is simply safer, and a whole lot faster to develop with. I like C/C++ as much as the next guy, but use the right tool for the job.
Not to start yet another religious war here, but C and Pascal are, IMHO, more or less equivalent, especially for the kinds of problems they tend to use at ACM programming contests. The languages have pretty close to a 1:1 correlation on features.
When I competed a few years ago, of the people I talked to there was a pretty strong bias towards C or C++. But there were also some good guys using Pascal, too. It's just a matter of which you were more comfortable with.
This sort of behaviour is perfectly legal under the DMCA and UCITA. Expect to see a lot more of this kind of thing as the megacorps treat the little people as little more than feudal serfs.
Yes, DMCA and UCITA are hot button issues here on slashdot.
Yes, Mattel is being really silly about this whole issue, IMHO.
The fact of the matter, though, is that UCITA has nothing to do with this issue, and DMCA is only marginally relevant, if at all.
Effecting change requires us to be open and honest about the issues in which we want action. Fearmongering and conglomerating unrelated issues doesn't help.
What's wrong with Linux threading? No really, I'm interested.
I dunno, but it's a fair sight better than the pthreads implementation on Digital^M^M^M^M^M^M^MTru64 unix. Ran a benchmark once that did uncontested mutex lock/unlock on a single thread on a 600Mhz EV56, and found I could only do 30000 iterations/sec.
This, on an architecture that has ISA support for a mutual exclusion instruction pair! And always has!
So, working it out, that gives us about 20,000 core cycles to do a mutex lock/unlock. On a quad-issue machine.
What message? That a bunch of long hairs impacted the workers commuting in and out of Seattle for 3 days? This isn't the sixties, the ITO protesters were horribly ineffective. The press that I saw never promoted the protesters issues, they just took pictures and reported on the exciting stuff, like rock throwing, masses in the streets, general civil unrest. The interviews I saw on CNN , ABC etc, were the field reporters asking the protesters why they were protesting. Almost every protesters response was something along the lines of " hey man, like, we're for freedom and all that." When asked specifically what they were protesting, most didn't know.
I must have been watching the OTHER WTO protests in Seattle that week, since that's not what I saw. Whipping on over to cnn.com, and doing a search for "seattle wto protests" yields two articles at the top of a long list. The first is a classical "free trade is good, even though sometimes it's hard to see that" argument, but the second says, more or less "the protests worked, people are thinking".
I do look down on most civil disobedience because there are better ways to go about making a change happen, specifically when dealing with the US government. Throwing rocks and bottles and staging sit ins does nothing to help reverse or modify the policies or the DMCA.
I'd argue that throwing rocks and bottles never helps anything, and nonviolent civil disobedience is probably not the most effective tack for changing the DMCA. However, nonviolent civil disobedience has a long history as an effective tool to work towards positive change.
Obvious examples are Mahatma Ghandi and the Indian liberation movement, Martin Luther King Jr, and the civil rights movement. Even today, your distasteful "long hairs" are using it effectively in smaller battles, such as the recently-ended tree sit in the Pacific Northwest. Maybe you're convinced that Ghandi could have written to the British governer of India and had much better results, but somehow, I doubt it. Many issues, including the WTO, require the attention of the public at large to start a change.
Thoreau wrote the now classic essay Civil Disobedience over a century ago, and it argues the point of civil protest in social action more eloquently than I can, here.
Please, don't denegrate a culture or method of social activism you obviously either don't want to or can't understand.
Capitalism does not == environmental havoc. The problem is that companies and individuals are shielded from having to bear the cost of their inneficiency thanks to the government subsidizing polluting activities.
Wow. Yet another Capitalism-is-a-magic-bullet-that-will-save-the-en tire-world-and-make-us-all-shiny-happy-p eople-if-you-just-get-out-of-the-way zealot.
Don't believe the hype.
Capitalism is the ideal solution for any situation wherein all costs are borne by their responsible parties. For much of our society this is true, and the free market works well. But it's not ALWAYS true.
Specifically, in the case of environmental degradation, there are several efficiencies that come into play. One base efficiency--really, the major efficiency stressed by pure capitalism is the maximization of pure monetary profit in the foreseeable future. So in the case of MythicalCorp, Inc., if it's possible to save a buck by spewing pollutants into your local river, it's most efficient to do so!
It's easy to argue that it's in the ultimate long-term interest of a corporation to preserve the environment, but how many companies actually do something about it? Very few. Environmental consciousness generally detracts from profits and the vast majority of stockholders, care more about the bottom line than about the long-term environmental consequences of their actions.
Since industry has, time and again, shown itself to not be self-regulating in this respect, I think it's an absolutely appropriate place for the government to get involved. The long-term costs of abusing the environment need to be made felt NOW, especially since a significant portion of the damage inflicted on our environment is not reversible in the short term.
Capitalism is great, but it's not the answer to everything. If given too free a rein, the invisible hand will slap you silly occasionally.
Repeat after me: Mhz only has any validity as a benchmark within an architecture. And even that validity is limited. A 400Mhz PII is NOT 33% faster than a 300Mhz PII. It's maybe 10%. To talk about Ghz Alphas as though they are at all similar to Ghz Intels is crazy.
Mhz within a given implementation of an architecture is the only thing that can be relevant, and even there it depends on the workload. You'll see linear scaling of performance on stuff that's not memory intensive, e.g. RC5 cracking. For most "real world" apps, you'll spend a great deal of your time bottlenecked somewhere other than the core, so the ratio of speedup to frequency will be less than linear.
It's pretty important to remember that implementations of architectures can vary drastically in capabilities, too. EV6 (the 21264) is a MUCH more aggressive microarchitecture than EV5 (21164). Even though you can get an EV5 or and EV6 at the same clock speed, the EV6 will trounce the EV5 in performance, due to higher bandwidth, out-of-order execution, etc.
On the other hand, there are cross-architecture frequency comparisons that can be valid, like, say, an EV5 vs. and UltraSparc II. Both are quad-issue, inorder cores with similar amounts of bandwidth. Frequency comparisons between the two aren't precise, but they are a pretty good rough comparison of performance between the two implementations...
I believe there are a number of reasons free hardware just won't work like free software. I could be (and actually, hope I am) wrong, but here goes:
Chips don't have a near-zero replication cost
With software, 99+% of the cost lies in the development and documentation of a software package. Distribution is virutally free, and the economies of scale are pretty ideal. This is not the case in hardware, especially on high-end chips; Many of these chips cost $50-$150 each to fabricate, when die size, yield, package, etc. are factored in. So the development costs for leading edge technology is an extremely small chunk of the overall cost of the chip.
Compare this to software, where the bandwidth cost of transmitting a new linux kernel tarball or the presseing cost of a distro CD is pennies or less, and that's a very significant difference. The lack of a significant replication cost is a key reason free software works; there's no real monetary risk involved in distributing CD's.
Chip design is not terribly modular
Yes, you can seperate the areas of a chip out into different boxes and define interfaces, etc., but even the best writting verilog is still fairly spaghetti-like. There are global signals that run everywhere, small changes can affect timing in many, many different areas, and it generally takes a pretty good knowledge of an entire chip to be able to make modifications without breaking things
Contrast this with (well-designed) software, in which there are generally interfaces and black boxes. In a free software project, I can usually go in and make edits relatively easily; the assumption that changing the internals of a black box without changing an interface won't break anything generally holds true. This is an important point that makes improvement by the masses feasible.
In every verilog or vhdl-based project on which I've worked, a small group of coordinated, very closely communicating engineers was critical to ending up with a good design.
Circuit design has a much steeper learning curve
To create a good VLSI project, you need to have quite a bit of training/experience under your belt. It's relatively easy to start programming and gradually learn what works and what doesn't. As a result, the pool of available programming talent dwarfs the pool of available circuit design talent.
Revisions are expensive
Referring back to ESR's C&B, releasing often is critical to the success of a free software project. Hardware doesn't afford that luxury, especially chip design. You can see the results in simulation, and possibly in some sort of FPGA emulation rapidly, but the end results are on VERY long term cycles. Software allows you to incorporate changes and include them in the end release product in minutes. Chip revisions cost thousands and thousands of dollars for new mask sets, which make frequent revisions pretty much impossibly for even the big corporations, much less the little guy.
Moore's law hurts
There are two major spectrums to address here.
For high end chips (Your Athlons, Coppermines, Alphas, etc.), the design deadline is absolutely critical. The luxury of "Being done when it's done" that is a central tenant of free software development doesn't work in chip design. There's a window of opportunity for a fabrication process that you have to hit, otherwise you'll either miss the process completely, or you'll be slower and more expensive than someone that did hit it. And what makes free software really cool is that it's often higher quality than the closed equivalents.
The other major area of chip design is embedded processor design. Here the argument is very similar, but performance/cost is king. Competing here is even harder, because the demand curve for these kinds of devices is so nearly horizontal that any cost increase really hurts.
Product lifetimes are generally short
This is related to the Moore's law point. Look at the linux kernel. It has been under active development for upwards of 10 years now, and it's just in the last year started to make a significant dent in the marketplace. With a hardware cycle, you typically have to scrap what you have at the moment every few years and start over, just to take advantage of the improving fabrication processes.
Free software is not a panacea for all processes in the world. There are very few, if any, solutions that are universal. On the other hand, I may eat my words later as problems have a way of being solved in unexpected ways. There are no intractable problems in the points I've listed, but there may be better solutions to the overal problem than open source.
Finally, a quick disclaimer. I work for a company that does MIPS-based chip design. So take everything I say with a grain of salt.:)
Carmack gets to release older engines and such things under the GPL, _knowing_ that nobody can take his work and build it into a competing closed source project. Granted, he can't cherry-pick ideas from the GPL stuff he seeded and use them in his closed stuff, but he doesn't need to, he has plenty of ideas of his own to use.
This seems to be a common misunderstanding about the GPL. There are two distinct issues here, and it's easy to get them confused.
In licencing something under the GPL, you do not give up your own, personal right to distribute your code under some other license at a later time. As copyright holder of that code, you are free to use that code any which way you please, including in other commercial projects if you so desire.
What the GPL does specify is that code released under the GPL cannot have that license revoked. In other words, if I, as copyright holder of foo.c, release it to Sally Hacker under the GPL, I cannot ever revoke Sally Hacker's GPL license to that code. In other words, I can't suddenly force Sally Hacker to not distribute the code I gave her under the GPL at any future date.
However, assuming I'm the sole copyright holder of the code I gave Sally, I am perfectly free to reuse that code in another product that is completely closed source and commercial, if I so desire. As copyright holder on that code, I can release it multiple times under whatever license I please. That's a basic part of being the copyright holder on something, and it is not a right you give up by releasing under the GPL
IMHO, this is a wonderful idea for getting software, and probably a step in the right direction, but I think there are a couple of other things that need to happen on this front as well.
There needs to be a universal interface for managing the removal of packages, too. RPM and others take some steps in that direction, but no one really gets it right, as it always seems necessary to override the automated system from time to time as it gets "confused". This is not all that difficult a problem; there just needs to be a central repository of reliable information on program/library dependancies. The biggest problem here is that the need for *all* programs to use this system for installation in order for the system to stay coherent.
The biggest problem I have with almost every OS in existance is the gradual buildup of cruft as the system stays up for longer and longer times. Removal modularity needs to be solved and solved in a complete and elegant manner to keep systems clean.
Source-level compatibility across free Un*x variants should not require something like autoconf to build across systems. The vast marjority of details autoconf takes care of should be considered bugs in both the Linux and the *BSD development trees until they come to a common ground. Of course, this is a sticky issue, as everyone always thinks their way is the "right" way to do something, and the passion about something being "right" is generally directly proportional to the triviality of the detail.
This will probably annoy many people, but given the Un*x market share of the free OS options, and the availability across a wide range of hardware platforms, moving forward while maintaining compatibility between free OSes is probably the best medium in terms of supporting interoperability while maintaining the ability to move forward. In other words, for most applications let's just not worry about getting it to run on SunOS or SCO or Tru64; it's more overhead than it's worth, and if we're truly innovating then the proprietary unices will follow our lead.
If these problems were solved, and an interface like/usr/ports existed for *BSD and Linux, life would be made an order of magnitude easier for both application developers and for end users.
Am I the only one that sees this as a bunch of Slashdot hype that's not too difficult to trace back to the involvement of one idolized Mr. Torvalds in the company? Designing low power high performance for mobile computing is not even remotely new; the StrongARM 110 debuted in 1996 in excess of 200 Mhz, showing parity performance with the high-end Pentiums at the time.
That processor really sipped power, burning 0.5W in its worst case.
Code morphing is a cool idea, and a very-low-power x86 implementation opens some interesting doors in terms of laptops and portable PC's. However, high-performance low-power CPU's have been around for quite a while; Crusoe is not new in this respect, and its existence doesn't mean that we're suddenly going to be swimming in cool portable devices that haven't been possible before.
Linus touching something doesn't necessarily turn it to gold...
Not at all true... self modifying code is still around not only on JIT compilers but in interpreted languages and even device drivers (Or how do you think some device drivers adjust in real time to hardware changes?). And it's not a dangerous technique in itself, but (As usual) when executed improperly it can be a wild beast (As most people discovered when thy installed their first Cyrix and AMD 486 processors and discovered most x86 code wouldn't run properly because of cache integrity issues)
Interpreted languages generally don't use self-modifying code. And it's not exactly a common technique in device drivers either. How many instances do *you* see in/usr/src/linux/drivers/*? Adaptability doesn't imply self-modification.
First of all, Harvard machines require separate instruction and data pipelines and memory spaces, and 99% of the CPU's on the market (General, Embedded, etc.) are Von Neumann machines which use a single space to store instruction and data. The thing is, newer CPU's (Even if they're Von Neumann desings)have separate caches for data and instructions and most self modifying code violates the cache integrity (See above) because the code is modified in the cache but never stored back into memory (Unless you use a write-through cache design which is impractical from the performace point of view).
This is probably more nitpick than anything else, but it's legitimate to refer to machines with split I/D caches as "Harvard architecture". The original meaning of completely seperate memory for I and D is not terribly relevant anymore and the distiction at the cache hierarchy level is fairly useful. Not many people talk about the IBM Mark series in anything other than a historical context.:)
BUT (And that's a big BUT:) if your JIT VM forces periodic cache writes to RAM (Not every time but enough times to ensure some sort of coherence if the cache and RAM are out of sync) you lose a bit of performance but gain a stabler setup.
To be correct across architectures, your JIT has to insure that you'll NEVER see the old icache data after you store to your program memory. The simplist way to do this is to force an icache flush on every write to instruction space. There may be a way of dynamically tracking this and doing some sore of Just In Time flush, especially if the processor doesn't offer any sort of selective flush in the icache. This could probably be done by invalidating a page with a special flag which causes a flush on TLB miss.
The point is largely moot though. I have serious doubts you'll ever get a consistent performance gain out of updating code on the fly; better to finish execution with a given translation and then go back and tweak the code ordering/generation based on profiling. In that case, flushing the icache is more or less free, from a performance perspective.
But even run time profiling is dubious at best, methinks. There's very little benefit in this space that can't be gotten more easily and at less cost from a combination of static compiler optimizations and dynamic architecture adaptations (e.g. branch prediction).
Slashdot Mirror
Precisely what I was going to say. But then I started thinking about it some more. You can't guarantee even a 1:1 ratio; purely random data will compress to slightly larger than original size, as you have to tag it.
Stepping back for a second, though, is this REALLY a problem for most systems? I'd be willing to bet that 99.999% of the time, multi-user systems run memory images that are at least moderately compressable. The curve of pessimistic memory availability vs. actual usage would yield something akin to a MTBF, which would be a good enough guarantee for those server spaces that are looking to save a few bucks.
Of course, memory usage limits would need to be in place to prevent some really obvious machine-crash attacks from users, but isn't that true already?
Interesting start, but they've still got memory, motherboards, and some other stuff to go. That's going to crank the price tag at least a couple thousand dollars...
I develop open source software in my free time. It's not what I'm paid to do. Startups like this are providing opportunities for open source hobbiests to turn the tables and do what they really like to do, not as a hobby on the side of something that pays the bills, but to pay the bills.
Granted, there are some potential pitfalls. Whenever you bring money into the equation, there exists a potential to lose the whole "itch-scratching" motivation in the wake of deadlines and targets. And often, corporations are antithetical to the whole concept of giving away your work for the sake of something bigger.
Look at some of the examples so far, though. Linus Torvalds is working for Transmeta, Alan Cox gets paid by Redhat, Eric Allman founded Sendmail, Miguel started Helix Code, and they're all still churning out the free software.
I see it as encouraging. An undercurrent in the whole open source movement is the recognition that pure greed-based capitalism isn't necessarily the only or best philosophy for life. The key seems to be prioritization; all the people I've mentioned have made giving away the code a higher priority than a paycheck, and, until I see reason not to, I trust them to continue to do so in their new positions.
The ARM arch doesn't have a 64-bit variant, so whatever chip is in there, it ain't ARM-based. 64-bit embedded RISC processor probably means MIPS, but not necessarily...
I can't recall ever seeing anything he's written that says anything other than positively glowing things about Intel. It's almost like he's trying to be the personal antidote to The Register, but whereas the Register is an admittedly biased gossip rag for IT folks, Mr Gwennap is supposed to be an independent analyst.
My point is, take anything he says about Intel with a very large grain of salt.
So if someone hacks the internal web server, you reboot, and end up with a machine that's still configured with a security hole? Sounds like a pretty bad idea to me...
Incremental backups nightly. If you're hacked, you find the hole, restore from backup if necessary, and patch the hole!
It's a power shift, no question. Though in the past it has been possible to block banner ads (Junkbusters has had a proxy server that blocks banner ads for years now) it has been enough of a pain that 99+% of people just aren't going to do it.
Add a menu option on the browser to do the same thing, and you've just made the blocking of banner ads much, MUCH easier for the end user, and lots of people will take advantage of it. I don't think anyone's going to argue against that.
The status quo has created a convenient space for marketers to lurk; they can position ads in such a way that you really have to have them visible in order to see the content you really want. What's key here is the (If you'll pardon the choir preaching on Slashdot...) practical lack of freedom of choice in the viewing of those ads. American society is so infested with advertising and marketing at the moment that the individual who doesn't want to see the pervasive marketing is having his or her freedoms whittled away day by day. It's gotten to the point where people used to the "freebies" provided by advertising question the very morality of providing a way to bypass ads.
It is not immoral to refuse to look at content you don't want to see.
Advertising is lauded as a way to make things free, but from a purely economic view, advertising as we see it today is wasteful in the extreme. Billions of dollars are spent every year to convince you that you need some new good in your life. 99.9% of the time this is pure consumerism hype; someone on the other end of the TV commercial, junk mail, or banner ad is trying to keep their economic niche alive by convincing you to budget money for their product or service that you were just as happy knowing nothing about.
The net result? You have to make more money to afford all the things you now "need". So you work harder, your productivity increases, the economy "grows" and politicians take credit for improving our lives. But is our standard of living really higher? Witness the infomercials that have to spend 15 minutes of a half hour slot trying desperately to convince you that your past advertising-driven purchases were all mistakes because this is the product you really need. There is a schizoprenia implicit to advertising that reveals its true nature.
With respect to banner ads and simple blocking, all that has happened is a power shift away from advertisers and towards end users. If end users are annoyed by ads, they can turn them off. If sites can't survive with users turning off those ads, the sites go down. There is no moral obligation to support that business model. If the cost of that business model is my freedom to choose what I look at, I say that cost is much, MUCH too high.
Host Name: <hemos.slashdot.org> IP Address: <192.168.1.53>
Host Name: <cmdrtaco.slashdot.org> IP Address: <192.168.1.83>
Host Name: <cowboyneal.slashdot.org> IP Address: <192.168.1.82>
Host Name: <emmet.slashdot.org> IP Address: <192.168.1.24>
Host Name: <xyzzy.slashdot.org> IP Address: <192.168.1.153>
Host Name: <plugh.slashdot.org> IP Address: <192.168.1.29>
(before anyone goes ballistic, it's a joke. Really! Look it up!)
The bandwidth/pin count ratio is very important for servers that need huge bandwidth. You can almost put 3 rambus interfaces on a chip for the pin cost of one DDR SDRAM interface. That's something that will make many chip designers take a good hard second look at Rambus
Also, something Tom Pabst never really covered was how much of the Camino performance pitfall was due to the chipset and how much was due to the memory protocol; it's perfectly possible to implement a MUCH more efficient Rambus memory controller than Camino does.
Having said all this, I think Rambus screwed up in many ways; they are notoriously arrogant in the industry, created a product that doesn't yield well, and tried to decommodotize a market, which, although possible, is definitely going against the flow in the industry. But that doesn't mean their technology is uninteresting or that Intel was smoking something when they decided to back Rambus.
DDR SDRAM would have taken a lot longer to come about if JEDEC thought they were sitting pretty with the next generation of mass-produced DRAM.
Oh well, you can fix it by hand...
(Sorry, couldn't resist...:)
So, say you could change something cosmetic about yourself genetically for a reasonable price. For example, what if a virus were available that triggered a whole-body genetic mutation, and the end result was a change in your genetic hair color?
Assuming you wanted that hair color, would you do it? Would the use of genetics for such things be unethical? How sacred is that individual genome that each one of us posseses?
What are the ethical uses of genetic information and modification? To cure disease? To select offspring attributes? There are LOTS of interesting questions that are going to be coming up in the next decade or two.
I'm really wondering about the Microsoft take on it though; it's hardly in keeping with their classic character. They want you to run a MS OS as your primary platform, and leverage that into other areas.
As I see it, allowing VMware to sell preinstalled with a Windows OS in the virtual machine is a threat to the whole primary platform idea. It looks like a way to make it easier for Linux vendors to edge into that primary platform space that they covet so much.
So I'm really wondering what MS sees as their benefit from this deal...
It's called threshold. 2 is a pretty damn effective filter, especially of noise like that.
Thankfully, it also tends to filter out the whining of people who don't have their threshold set above 0...
Not to start yet another religious war here, but C and Pascal are, IMHO, more or less equivalent, especially for the kinds of problems they tend to use at ACM programming contests. The languages have pretty close to a 1:1 correlation on features.
When I competed a few years ago, of the people I talked to there was a pretty strong bias towards C or C++. But there were also some good guys using Pascal, too. It's just a matter of which you were more comfortable with.
Yes, DMCA and UCITA are hot button issues here on slashdot.
Yes, Mattel is being really silly about this whole issue, IMHO.
The fact of the matter, though, is that UCITA has nothing to do with this issue, and DMCA is only marginally relevant, if at all.
Effecting change requires us to be open and honest about the issues in which we want action. Fearmongering and conglomerating unrelated issues doesn't help.
I dunno, but it's a fair sight better than the pthreads implementation on Digital^M^M^M^M^M^M^MTru64 unix. Ran a benchmark once that did uncontested mutex lock/unlock on a single thread on a 600Mhz EV56, and found I could only do 30000 iterations/sec.
This, on an architecture that has ISA support for a mutual exclusion instruction pair! And always has!
So, working it out, that gives us about 20,000 core cycles to do a mutex lock/unlock. On a quad-issue machine.
Never did track down what was going wrong...
I must have been watching the OTHER WTO protests in Seattle that week, since that's not what I saw. Whipping on over to cnn.com, and doing a search for "seattle wto protests" yields two articles at the top of a long list. The first is a classical "free trade is good, even though sometimes it's hard to see that" argument, but the second says, more or less "the protests worked, people are thinking".
I do look down on most civil disobedience because there are better ways to go about making a change happen, specifically when dealing with the US government. Throwing rocks and bottles and staging sit ins does nothing to help reverse or modify the policies or the DMCA.
I'd argue that throwing rocks and bottles never helps anything, and nonviolent civil disobedience is probably not the most effective tack for changing the DMCA. However, nonviolent civil disobedience has a long history as an effective tool to work towards positive change.
Obvious examples are Mahatma Ghandi and the Indian liberation movement, Martin Luther King Jr, and the civil rights movement. Even today, your distasteful "long hairs" are using it effectively in smaller battles, such as the recently-ended tree sit in the Pacific Northwest. Maybe you're convinced that Ghandi could have written to the British governer of India and had much better results, but somehow, I doubt it. Many issues, including the WTO, require the attention of the public at large to start a change.
Thoreau wrote the now classic essay Civil Disobedience over a century ago, and it argues the point of civil protest in social action more eloquently than I can, here.
Please, don't denegrate a culture or method of social activism you obviously either don't want to or can't understand.
Wow. Yet another Capitalism-is-a-magic-bullet-that-will-save-the-en tire-world-and-make-us-all-shiny-happy-p eople-if-you-just-get-out-of-the-way zealot.
Don't believe the hype.
Capitalism is the ideal solution for any situation wherein all costs are borne by their responsible parties. For much of our society this is true, and the free market works well. But it's not ALWAYS true.
Specifically, in the case of environmental degradation, there are several efficiencies that come into play. One base efficiency--really, the major efficiency stressed by pure capitalism is the maximization of pure monetary profit in the foreseeable future. So in the case of MythicalCorp, Inc., if it's possible to save a buck by spewing pollutants into your local river, it's most efficient to do so!
It's easy to argue that it's in the ultimate long-term interest of a corporation to preserve the environment, but how many companies actually do something about it? Very few. Environmental consciousness generally detracts from profits and the vast majority of stockholders, care more about the bottom line than about the long-term environmental consequences of their actions.
Since industry has, time and again, shown itself to not be self-regulating in this respect, I think it's an absolutely appropriate place for the government to get involved. The long-term costs of abusing the environment need to be made felt NOW, especially since a significant portion of the damage inflicted on our environment is not reversible in the short term.
Capitalism is great, but it's not the answer to everything. If given too free a rein, the invisible hand will slap you silly occasionally.
Mhz within a given implementation of an architecture is the only thing that can be relevant, and even there it depends on the workload. You'll see linear scaling of performance on stuff that's not memory intensive, e.g. RC5 cracking. For most "real world" apps, you'll spend a great deal of your time bottlenecked somewhere other than the core, so the ratio of speedup to frequency will be less than linear.
It's pretty important to remember that implementations of architectures can vary drastically in capabilities, too. EV6 (the 21264) is a MUCH more aggressive microarchitecture than EV5 (21164). Even though you can get an EV5 or and EV6 at the same clock speed, the EV6 will trounce the EV5 in performance, due to higher bandwidth, out-of-order execution, etc.
On the other hand, there are cross-architecture frequency comparisons that can be valid, like, say, an EV5 vs. and UltraSparc II. Both are quad-issue, inorder cores with similar amounts of bandwidth. Frequency comparisons between the two aren't precise, but they are a pretty good rough comparison of performance between the two implementations...
Compare this to software, where the bandwidth cost of transmitting a new linux kernel tarball or the presseing cost of a distro CD is pennies or less, and that's a very significant difference. The lack of a significant replication cost is a key reason free software works; there's no real monetary risk involved in distributing CD's.
Contrast this with (well-designed) software, in which there are generally interfaces and black boxes. In a free software project, I can usually go in and make edits relatively easily; the assumption that changing the internals of a black box without changing an interface won't break anything generally holds true. This is an important point that makes improvement by the masses feasible.
In every verilog or vhdl-based project on which I've worked, a small group of coordinated, very closely communicating engineers was critical to ending up with a good design.
Referring back to ESR's C&B, releasing often is critical to the success of a free software project. Hardware doesn't afford that luxury, especially chip design. You can see the results in simulation, and possibly in some sort of FPGA emulation rapidly, but the end results are on VERY long term cycles. Software allows you to incorporate changes and include them in the end release product in minutes. Chip revisions cost thousands and thousands of dollars for new mask sets, which make frequent revisions pretty much impossibly for even the big corporations, much less the little guy.
For high end chips (Your Athlons, Coppermines, Alphas, etc.), the design deadline is absolutely critical. The luxury of "Being done when it's done" that is a central tenant of free software development doesn't work in chip design. There's a window of opportunity for a fabrication process that you have to hit, otherwise you'll either miss the process completely, or you'll be slower and more expensive than someone that did hit it. And what makes free software really cool is that it's often higher quality than the closed equivalents.
The other major area of chip design is embedded processor design. Here the argument is very similar, but performance/cost is king. Competing here is even harder, because the demand curve for these kinds of devices is so nearly horizontal that any cost increase really hurts.
Free software is not a panacea for all processes in the world. There are very few, if any, solutions that are universal. On the other hand, I may eat my words later as problems have a way of being solved in unexpected ways. There are no intractable problems in the points I've listed, but there may be better solutions to the overal problem than open source.
Finally, a quick disclaimer. I work for a company that does MIPS-based chip design. So take everything I say with a grain of salt. :)
This seems to be a common misunderstanding about the GPL. There are two distinct issues here, and it's easy to get them confused.
In licencing something under the GPL, you do not give up your own, personal right to distribute your code under some other license at a later time. As copyright holder of that code, you are free to use that code any which way you please, including in other commercial projects if you so desire.
What the GPL does specify is that code released under the GPL cannot have that license revoked. In other words, if I, as copyright holder of foo.c, release it to Sally Hacker under the GPL, I cannot ever revoke Sally Hacker's GPL license to that code. In other words, I can't suddenly force Sally Hacker to not distribute the code I gave her under the GPL at any future date.
However, assuming I'm the sole copyright holder of the code I gave Sally, I am perfectly free to reuse that code in another product that is completely closed source and commercial, if I so desire. As copyright holder on that code, I can release it multiple times under whatever license I please. That's a basic part of being the copyright holder on something, and it is not a right you give up by releasing under the GPL
- There needs to be a universal interface for managing the removal of packages, too. RPM and others take some steps in that direction, but no one really gets it right, as it always seems necessary to override the automated system from time to time as it gets "confused". This is not all that difficult a problem; there just needs to be a central repository of reliable information on program/library dependancies. The biggest problem here is that the need for *all* programs to use this system for installation in order for the system to stay coherent.
- Source-level compatibility across free Un*x variants should not require something like autoconf to build across systems. The vast marjority of details autoconf takes care of should be considered bugs in both the Linux and the *BSD development trees until they come to a common ground. Of course, this is a sticky issue, as everyone always thinks their way is the "right" way to do something, and the passion about something being "right" is generally directly proportional to the triviality of the detail.
If these problems were solved, and an interface likeThe biggest problem I have with almost every OS in existance is the gradual buildup of cruft as the system stays up for longer and longer times. Removal modularity needs to be solved and solved in a complete and elegant manner to keep systems clean.
This will probably annoy many people, but given the Un*x market share of the free OS options, and the availability across a wide range of hardware platforms, moving forward while maintaining compatibility between free OSes is probably the best medium in terms of supporting interoperability while maintaining the ability to move forward. In other words, for most applications let's just not worry about getting it to run on SunOS or SCO or Tru64; it's more overhead than it's worth, and if we're truly innovating then the proprietary unices will follow our lead.
No, he's the #2 man in the kernel because he's a damn fine hacker and contributor.
The gift might give insight to him as a pretty cool human being, but I for one am glad it means nothing in the kernel uberhacker pecking order. :)
That processor really sipped power, burning 0.5W in its worst case.
Code morphing is a cool idea, and a very-low-power x86 implementation opens some interesting doors in terms of laptops and portable PC's. However, high-performance low-power CPU's have been around for quite a while; Crusoe is not new in this respect, and its existence doesn't mean that we're suddenly going to be swimming in cool portable devices that haven't been possible before.
Linus touching something doesn't necessarily turn it to gold...
Interpreted languages generally don't use self-modifying code. And it's not exactly a common technique in device drivers either. How many instances do *you* see in /usr/src/linux/drivers/*? Adaptability doesn't imply self-modification.
First of all, Harvard machines require separate instruction and data pipelines and memory spaces, and 99% of the CPU's on the market (General, Embedded, etc.) are Von Neumann machines which use a single space to store instruction and data. The thing is, newer CPU's (Even if they're Von Neumann desings)have separate caches for data and instructions and most self modifying code violates the cache integrity (See above) because the code is modified in the cache but never stored back into memory (Unless you use a write-through cache design which is impractical from the performace point of view).
This is probably more nitpick than anything else, but it's legitimate to refer to machines with split I/D caches as "Harvard architecture". The original meaning of completely seperate memory for I and D is not terribly relevant anymore and the distiction at the cache hierarchy level is fairly useful. Not many people talk about the IBM Mark series in anything other than a historical context. :)
BUT (And that's a big BUT :) if your JIT VM forces periodic cache writes to RAM (Not every time but enough times to ensure some sort of coherence if the cache and RAM are out of sync) you lose a bit of performance but gain a stabler setup.
To be correct across architectures, your JIT has to insure that you'll NEVER see the old icache data after you store to your program memory. The simplist way to do this is to force an icache flush on every write to instruction space. There may be a way of dynamically tracking this and doing some sore of Just In Time flush, especially if the processor doesn't offer any sort of selective flush in the icache. This could probably be done by invalidating a page with a special flag which causes a flush on TLB miss.
The point is largely moot though. I have serious doubts you'll ever get a consistent performance gain out of updating code on the fly; better to finish execution with a given translation and then go back and tweak the code ordering/generation based on profiling. In that case, flushing the icache is more or less free, from a performance perspective.
But even run time profiling is dubious at best, methinks. There's very little benefit in this space that can't be gotten more easily and at less cost from a combination of static compiler optimizations and dynamic architecture adaptations (e.g. branch prediction).