You can legally distribute diffs (even somehow in binary form) by themselves under any license you want, but when those diffs are included with (applied to) my code, in order for you to legally distribute my code, you must release those changes under my license, because those are the terms of my license. Bottom line: Read the GPL. It's not that long, read it.
I did!
I agree it's pretty much cut-and-dried in a desktop situation, but it's pretty tough to separate 'your' code from 'my' code in an embedded environment... unless you go whole hog and built a read-only disk into Flash ROM. I understand there are some embedded Linux systems doing that sort of thing, but I certainly don't want to. What I would want to do is to strip down the kernel and and so forth to the absolute minum I need, and get my threads and interrupts up and running ASAP...
Ya know how your hand hurts from clenching a mouse too much? Think how it will be to hold a pen all day.
Exactly. The great thing about a (suitably formed) mouse or trackball is that your hand is usually at rest, and muscle contraction happens a small part of the time. On the other hand, holding a pen always needs some contraction - unless you get one of these lumpy things for arthritics. Yes, the pen is the right thing for drawing, but not for when you need to switch back and forth.
Also, when you switch a hand back and forth between a mouse/trackball and the keyboard, your hand always falls back into the 'rest' position. Picking up a pen again every time requires additional effort and movements.
Touch screen would be a lot better. I don't know why they aren't more popular.
To get to a touchscreen over a normal monitor, you need to hold your hand and forearm up all the time... very tiring. So touchscreens will become popular when they're built into either the desk surface or into a drafting table, and in a way which doesn't interfere with the keyboard, and with sufficient resolution... so that's why. In 10 years, perhaps, when we get programmable touch-sensitive paper?
I'm really sick of magazines that are at least 50% advertising. Every once in a while I buy a magazine and rip out any of the pages with ads on both sides. It's amazing how much of those things is made up of their very thin content. How do they even survive?
I suppose most non-US residents will agree with me here... in the last 5 years, since the Internet became widely available, magazines are obsolete as newssources. Even now, with airmail distribution, I get technology news and product reviews 1 or 2 months before they appear in the magazines.
So there are two remaining reasons to buy magazines : 1) enclosed CDs - also becoming obsolete due the facility of downloading, and 2) the ads.
I have complete sets of most computer magazines, from issue#1 on, from 1977 to about 1993... after that I buy only one or two, every couple of months or so, just to look at the ads... and this won't last. So what do I still buy? Wired, because I like the ads and graphic layout; "How" (every 6 months or so, same reason), and some non-computer mags. But my magazine budget is not even 10% of what it was 5 years ago.
I'm evaluating the possibility of using Cygnus or something like it as basis for a medical embedded device. No CD drive, everything is in Flash ROM, no user tweaking is possible, and my users aren't computer literate at all.
So supposing I overcome my reluctance of going back 30 years to a command-line development system:-), am I obliged to ship a CD with every unit? Or can I just publish diff files on my website? And where does my advantage go if I publish my source code for my competitors to download, anyway?
Yes, I've read the GPL and the other comments here, but I'm still not sure for this particular case...
Smaller transistor sizes don't necessarily make the chip run faster. The problem is, as the transistors get smaller, the wires get smaller as well. Smaller wires have higher resistance and have more capacitive contact with surrounding wires, and so at a certain point, the delays in the wires start to dominate and the delays in the chip actually increase as the chip is minaturized.
It doesn't quite work that way.
These new transistors have much smaller gate thickness, which means less capacitance, which means higher switching speeds, but also a lower breakdown voltage, which means less power. Making the transistors smaller also allows them to be crowded together, which reduces wire length (not necessarily wire thickness, as you think). So the net effect is positive: everything gets smaller and faster and uses less power.
Also these new transistors can be layered one over the other, which is practically impossible with today's horizontal transistors. This also reduces average interconnect lengths. And contrary to what some posters have been surmising, the reduced power requirements balance the greater heat dissipation, so no new cooling techniques are needed.
They will probably use a combination of two techniques, namely, using a standard logic block ringed with interconnect patterns, and evolution.
The self-assembly process isn't understood yet, from what I gather from the article, and it may not be possible to adapt it to patterns more complicated than an array of round pillars - but if it is, you'll get something like a huge matrix of standard blocks. If you figure out the interconnects correctly so they'll self-align, you'll get something which can be programmed by an extension of today's FPGA techniques... either permanently with a laser probe or by injecting serial data streams into the array.
There have been some interesting papers published (sorry, can't find the URL now) about evolutionary programming of FPGA's... that may also be applicable.
Finally, they recently figured out how to make vertical transistors (unlike the horizontal ones used today) which can be stacked in 3 dimensions. So I think we'll see logic and memory chips using these principles in a relatively short time - 5 or 10 years is my guess.
I'll say you can't be confident. Given the speed at which developments move these days, in all areas of science and technology, who would dare to predict exactly where we'll be in 50 years time?
I've followed this subject with great interest for many years. Although I'm not qualified to comment on the fine technical aspects, high-energy particle physics is bound to obey certain time steps... the author is no doubt simply extrapolating from a curve of delivery dates vs. energy of current and planned accelerators, and marking 50 years (plus/minus 50, you will notice) as a likely date when accelerators will reach a certain energy range.
This is the range where he's reasonably confident that there'll be enough significant events to either rule out all but one of the competing theories, or to merge them into one unified theory. At the same time he seems to consider that this is a sufficiently long time for the required mathematical techniques to be worked out, and that enough computing power will be available.
Given that construction times of these accelerators are now over a decade, and likely to get worse they bigger they get - not to speak of the political and financial contortions - his estimate seems quite reasonable.
Consider a parallel situation where most/.ers will have a better feel for things. Suppose you were asked to estimate when 1024-bit (or whatever other magic number you prefer) encryption will be broken. You can estimate the computing power necessary, make an estimate when this will be available by Moore's Law, shave off some years by postulating a cluster of some kind (Beowulf, if you wish;-)), postulate both a breakdown of Moore's Law at some future time and/or a new technology that goes around that, and so forth. So you'll probably end up with some fuzzy range of so-and-so-many decades. See? If you know the field, it's not so hard.
Then again, if the singularity posited by SF writer Vernor Vinge and cohorts comes around - estimates are somewhere in the 22nd century - everything will be either solved in a very short period of time or declared uninteresting...
Jon, congratulations. Easily one of the best articles I've ever read on/. - have you thought of submitting it to the Whole Earth Review? This theme deserves wide discussion.
The problem is that everyone has a different idea of what medical software actually is. Some posters seem to think it refers to the programs that control pacemakers, ecg's, and other medical tools and electronics. Others include even programs used to transfer information among doctors.
I agree... there are two types of "medical software": embedded software for medical instruments, and patient information software. Requirements and processes (and, for that matter, regulatory requirements) are completely different for each...
For over 15 years I've written embedded software for medical devices, and only twice I've found it useful to incorporate source code from outsiders... even so after a very long review and licensing process. For many market segments the only way to outsell competitors is by having better software. I see no future for OSS here at all.
In patient information software the outlook is completely different. Interoperability and security are much more important than proprietary features, so there may be significant opportunities for OSS-based systems.
...that a workable approach at fusion technology should come along. Nothing else will be practical in the long run.
As it's clear that very few people are still throwing money at "cold fusion" setups, the "hot fusion" variation described in the article seems like the only way to go right now. Once they lick the symmetricity problem - possibly by setting up some positive feedback in the plasma to keep the reaction shape spherical in the crucial nanoseconds - there should be more progress.
Getting parts of the reactor chamber destroyed at every pulse is relatively the easiest part to get around...
Texas Instruments has dominated the market for digital signal processor chips for years. It looks like this is about to change big-time.
and
Texas Instruments is the Intel of the DSP industry, except that they make a better product and don't throw their weight around.
Texas used to be tops at DSP, but AFAIK Motorola has passed them some time ago. Their 56000 series was a huge success and in fact the G4 is an audacious attempt to merge the DSP and MPU lines at the high end - it can run circles around the top TI DSP.
Fe people remember that the G4 was originally launched at NetWorld+InterOp. The demo they had was emulating over 30 V.34 modems on a single G4... not bad at all.
While the ISA bus is seriously slow, there are several applications for which an ISA bus in easily adiquate. A modem for instance. Since a modem is far slower than even the ISA bus, there is no need to put it on a PCI bus. On the subject of PCI modems, does anyone make a non winmodem for the PCI bus? I have looked a little, and only found winmodems.
I've always wondered why someone would prefer an internal modem. Everytime an electrical storm hits my town, I hear scare stories of PC users losing their modem cards and motherboards, whereas the Mac users just get their external modems vaporized... now with iMacs selling so well, this kind of thing is starting to happen on the Mac side too. Now that USB modems are coming out, I always recommend external modems for everybody.
If I were to buy a motherboard (with no regard to price), it would have an AGP slot, at least 6 PCI slots, at least 2 EISA/VL slots (for those unfamiliar with the protocol, EISA slots can take ISA cards, and VL slots are a physical extension on the back of an ISA or EISA slot), and at least one preferably two MCA slots.
Sounds like the ideal system for a hardware hacker/developer (although even a developer nowadays probably wouldn't be doing stuff for legacy systems). For software developers or plain users, the simpler the system, the better...
For server side stuff, and for embedded stuff, Java is the way of the future
Allow me to disagree somewhat with this paragraph only... unless you're talking about these new embedded servers which are starting to appear. In those, one's not concerned about performance, it's sufficient to get your little box actually serving pages out to the net. Portability's not important either for embedded servers; code compactness perhaps, as memory is always limited.
For real-world servers writings CGIs in Java is an easy way to get things rolling, but performance-wise they just don't cut it, and you get an extra layer of software where bugs may creep in.
For non-server embedded systems, I wouldn't trust Java in the foreseeable future to meet real-time scheduling requirements... and who needs portable embedded code, for that matter? Most embedded designers don't trust anything they don't have full source code for. How would you go about debugging a Java embedded system with a data analyzer, anyway? Just the thought makes me queasy...
All this periodic hoo-haa about interpreted languages leaves me cold... there are cycles where they surface and go under again without a trace. IBM's RPG and UCSD p-code were early examples. Middle-period Microsoft apps were partially interpreted, and good riddance! Forth is about the only interpreted language I'd use in an embedded system - I've written a few interpreters for that myself. Even so, it takes care and optimization for each case.
An enormous penguin, rendered with ASCII in various colors, parts of the statue are unfinished at certain points, allowing one to glimpse Linus-faced figures inside, frantically typing at (obviously mouse-less) terminals.
Around the statue, masses of mindless/.ers kowtow and offer sacrifice...
A tunnel is shown being dug underneath the idol, with Gates-faced sappers readying dynamite charges.
At one side, a puzzled user is being interviewed by a reporter, asking "...but does it run WordStar?"
ive my ignorance, but I'm not to educated on the "under the hood" stuff in *nix environments, but is this a new thing?
It's decades old, in fact. When I was debugging patches to DOS/360 and OS/360 (for IBM mainframes) and MCP (for Burroughs mainframes) a core dump, directed to the high-speed printer, was an invaluable tool.
Once RAM sizes passed the megabyte mark, the effectiveness was much reduced; it was just too much paper to page through. There was enough hardware information (3 extra tag bits for each 48-bit word) to allow the MCP core dump to be formatted into data, code, and stack areas. The IBM dumps were tough going to decode. On a modern microcomputer, of course, lots of other things like page tables and registers have to printed out, too...
RC, petroleum derived from cambrian era plants, while the dinosaurs were mesozoic.
Frankly, I was puzzled by this reference to petroleum-generating dinosaurs, all previous literature on the subject - at least what I've read - emphasized plant mass as the presumed source for petroleum.
A little thinking, also, will show that the total biomass for dinosaurs, or any animals even, (not considering the "era") must have been insignificant compared to that of plants or even microorganisms or insects, as is still the case today.
IMHO Gold may well be right in principles, although wrong in some particulars. The original "cambrian biomass" theory for oil/petroleum is quite dated and has suffered little revision... hydrocarbons are known to occur in great quantities elsewhere in the universe, and a layer of hydrocarbons in the Earth would certainly be hospitable to life. Life can potentially be found at any energy gradient, as the example of deep-sea hot spots shows.
"I told them I would like to teach advanced physics," Gold remembers. "They said that was fine. But since I had never studied any physics, I had to learn it myself night by night, before each lecture." I'm impressed.
This sentence caught my eye too... impressive, but not unheard of.
In fact, several excellent teachers I've had told me similar stories. IIRC even such luminaries as Richard Feynman had to do this sort of thing on occasion... the combination of extreme time pressure and the memories of very recent learning can help to produce a very successful teaching experience. Can lead to ulcers, though...
While this is a worthwhile subject that most CSci people tackle, I don't feel that the/. crowd cares to get this low level. It strikes me that the core competencies are more script oriented (Perl, etc...), and thus aren't oriented toward the "science" of computers.
As a part-time embedded systems designer, I routinely have to consider both hardware and software issues. And in my estimate the mental models one builds based on some knowledge about both sides of the "science" help a lot with solutions design.
Regarding the book itself, I've skimmed through the version published on the web. Although a few parts are somewhat dated, it's seems to be quite useful for teaching principles. In the real world things aren't as clear-cut of course; I spend much more time ferreting out race conditions, worrying about shielding, decoupling and board layout, power supply ripple specs and so forth, rather than designing finite state machines. I've yet to see a textbook that addresses these issues in a useful way... let alone the hardware/software interactions.
For instance, consider something like a Palm Pilot. It's in sleep mode, and when you press a key, it wakes up and an interrupt routine is executed, which then does whatever the key means. On waking up, you get a huge power spike - the CPU's power consumption increases a thousandfold inside a few microseconds - and if the board designer hasn't allowed for that, when the power spike bounces back down the interrupt routine may crash. The programmer can stare at a source listing or emulator trace for months with no progress at all unless he knows about such hardware details.
I haven't seen demographics about the "slashdot crowd", but my impression is that perhaps half are quite young - they haven't messed around with valve radios or Heathkits before taking up programming [insert half-senile chuckle here]. Well, the hardware side of the business has progressed a lot - perhaps even more than the software side - since I started out 30 years ago... my advice to everybody is to take some time to study up on what's happening on the other side of the fence, it's worth it.
Common sense would seem to dictate that CONVERTING that 5-10% that IS different, would be a trivial effort compared to the effort put into writing the 90-95% that is IDENTICAL across ALL THREE platforms.
That's perfectly doable if the 5-10% were separated at birth, so to speak, from the 90-95%. In other words, if the software (game or not) were specifically developed from the beginning for a cross-platform destiny... in practice, everything is so intertwined that you're better off throwing 50-60% of the code away and rewriting it from scratch.
This can usually be done only by the original programmers - I doubt that a subcontractor (as was the case here) would succeed. I've done a few Windows-to-Mac ports (not games) and the way the originals were written, less than 40% were usable in one case, the others needed a from-the-ground-up rewrite. Of course, the marketing/accounting guys think this is outrageous and never budget for that, as it may take nearly as much time and money as it did for the original. So much for calling it a "port".
I find it hard to belive that a small company like Id somehow has the resoueces and programming competancey to release all three versions of a game SIMULTANEOUSLY (as Carmack has promised to do with Q3), whilst a gigantic company like Sierra can't come up with the resources or programming skill to release seperate versions at all!?!?!?
Welcome to the real world. The larger a company is, the less agility they have for this sort of thing... there's an optimum size for doing this and Id seems to have hit that sweet spot. If they put in more people the extra guys would just be stepping on each other's toes and spend their time writing interdepartment memos.
Seems to me, that given the minimal necessary effort (unless my recollection of Carmack's.plan is REALLY fuzzy, or he was lieing) to convert a game, and the potential for easy money; the only reason a game would NOT be released simultaneously for windoze, Linux, and Macintosh, is purely political.
I agree to a certain extent, but I'd consider internal politics as the culprit rather than postulate a "Seattle Conspiracy". My experience is that porting software once it's been released is an uphill battle against factions which don't want to commit significant resources to what they think is "only a quick port". Successful cross-platform apps are done in-house by very experienced teams and all at the same time. Period. Getting an external contractor do it later is foolhardy.
Re:Best Part of Snow Crash : the first page
on
Snow Crash
·
· Score: 1
The reviewer overlooked the very best part of Snow Crash: the first chapter...
Quite possibly the best first chapter in recent SF. Heck, make that the best first page ever! People complain about the ending, but I frankly can't even remember what the ending is... anybody who can write a first page like that can be forgiven any ending whatsoever.
And of course, the book practices what it preaches - the first page is a virus carrier for selling further copies of the book. I may have helped sell over 20 copies just by ordering people to "read this!" in a bookstore.
I'd love to ask him about whether YT is Mrs Matheson
Despite later comments in this thread, why would he throw in the "chiseled spam" comment if they weren't the same person - or analogues in parallel universes?
But I second (or n+1nd) the motion for a Neal Stephenson interview. My question would be when "Spew", previewed years ago in Wired, hasn't come out yet...
I've e-mailed them (or should I say, you?;-) a couple of times, nobody replied - the website hasn't been updated for several months - the mailing list archives are ancient. I thought the project had been cancelled, in fact.
Would you have an URL for downloading the full uClinux source? The link I saw on the website only leads to a couple of diff files - not very practical for me.
... for us embedded system designers. I'm halfway through designing a new product line based on the DragonBall EZ, and am waiting for the exact pinout of the new chip to published, to make sure my board will be upwards-compatible.
Regarding the 256-color capability, it was about time. It's getting hard to specify the 16-level grayscale LCDs that were supported in the EZ, most manufacturers are abandoning them.
Does anyone in the audience have experience with Motorola's PPSM operating system for the DragonBall? I'd like to try it, but their website is mum about licensing details...
I suspect this stems from the notion of "split-brain psychology," a model of the human mind which has distinct hemispheres processing different types of thought: the left brain primarily handling logical and verbal skills, the right brain handling conceptual (non-verbal) and creative skills. The theory is descibed quite well in Betty Edwards' book, "Drawing on the Right Side of the Brain," a very good read even for non-artists...
I have both of her books, which are indeed excellent... although I'm usually uncomfortable with the adoption of the split-brain concept by pop/amateur psychologists.
Specifically in programming, whether algorithm design or actual coding, I think both hemispheres, or one might say more accurately, both verbal and non-verbal processes are involved. While the actual hierarchical structuring is essentially non-verbal, at the same time much attention must be paid to verbal fields like naming of variables, programming language syntax, typing... even visual program layout isn't completely non-verbal. Though E.R. comments: Coding, I believe, is a conceptual task like drawing, not a verbal one, despite being built up of little words like "while" and "if." When in Deep Hack Mode, one considers "while" as a programmatic concept, not a word, and the movements necessary to convey that concept (typing) are performed out of rote rather than requiring verbal concentration. A skilled musician may experience the same thing...the names and durations of the individual notes are no longer something to be concentrated on while playing...the body is "tuned" to carry them out and string them together as an act of continuous non-verbal expression.
Allow me to suggest that this isn't necessarily a valid analogy, as recent research seems to indicate that this sort of extremely skilled motor activity actually involves learning by the spinal neurons; that is, the "macros" are more in the firmware than in the software, if one can say that. Furthermore, I doubt that typing a word like "while" automatically as if it were a chord is as disconnected from verbality as is playing a chord on the piano... after all, you're reading it while typing it, and need visual feedback to see if it's typed correctly. And if you're not a native English speaker, you actually need to be even more attentive...
Allow me to add Steve Reich's "Music for 18 Musicians" and anything by Penguin Cafe Orchestra to that list.
I know Reich, never heard of the P.C.O. Thanks for the tip - I'll look them/he/she/it up. I also forgot to mention one of the grandfathers of minimalism, Terry Riley. His classic "In C" was reissued recently. You may also like the "Tibetan Bells" records and early Kraftwerk.
I can program and debug to any music that does not have words. I believe that it helps me concentrate better by shutting out distracting noises.
Well, I notice that lots of people are simply posting their preferences without going into considerations why music helps with coding (or indeed most creative activity). FWIW, my own preferences are Philip Glass, Weather Report, John Coltrane, Jan Garbarek, David Darling, Keith Jarrett, some Pink Floyds, and new age/ethnic stuff like Uakti, Don Harriss and early Jean-Michel Jarre.
Notice that none of these have words - I occasionally listen to Joni Mitchell too, because the melody is sufficiently complex to override voice recognition. There's a very interesting book by Ray Jackendoff, "Consciousness and the Computational Mind" (currently unfortunately out of print, but any university library should have it). Jackendoff is both a linguist and a musician and has many interesting insights about the similarities between music and language - listening to wordless music is like listening to poetry in a foreign language, in his view, as the semantic part of language processing is shut out and you just do the lower-level phonetic and syntax processing - sound and rhythm.
As to why this should help coding, I'd say that the way music is structured - several levels of hierarchy, loops, variations on a theme, macros, and so forth - parallels mental models of software. Therefore the same neuron clusters should be involved, and there would be no conflict in doing both at the same time.
I also conjecture that nearly everybody listens to CDs, and not radio - since you already know the records, there are no surprises and the repetition actually stimulates you to create new patterns in your coding.
Slashdot Mirror
Bottom line: Read the GPL. It's not that long, read it.
I did!
I agree it's pretty much cut-and-dried in a desktop situation, but it's pretty tough to separate 'your' code from 'my' code in an embedded environment... unless you go whole hog and built a read-only disk into Flash ROM. I understand there are some embedded Linux systems doing that sort of thing, but I certainly don't want to. What I would want to do is to strip down the kernel and and so forth to the absolute minum I need, and get my threads and interrupts up and running ASAP...
Exactly. The great thing about a (suitably formed) mouse or trackball is that your hand is usually at rest, and muscle contraction happens a small part of the time. On the other hand, holding a pen always needs some contraction - unless you get one of these lumpy things for arthritics. Yes, the pen is the right thing for drawing, but not for when you need to switch back and forth.
Also, when you switch a hand back and forth between a mouse/trackball and the keyboard, your hand always falls back into the 'rest' position. Picking up a pen again every time requires additional effort and movements.
Touch screen would be a lot better. I don't know why they aren't more popular.
To get to a touchscreen over a normal monitor, you need to hold your hand and forearm up all the time... very tiring. So touchscreens will become popular when they're built into either the desk surface or into a drafting table, and in a way which doesn't interfere with the keyboard, and with sufficient resolution... so that's why. In 10 years, perhaps, when we get programmable touch-sensitive paper?
I suppose most non-US residents will agree with me here... in the last 5 years, since the Internet became widely available, magazines are obsolete as newssources. Even now, with airmail distribution, I get technology news and product reviews 1 or 2 months before they appear in the magazines.
So there are two remaining reasons to buy magazines : 1) enclosed CDs - also becoming obsolete due the facility of downloading, and 2) the ads.
I have complete sets of most computer magazines, from issue#1 on, from 1977 to about 1993... after that I buy only one or two, every couple of months or so, just to look at the ads... and this won't last. So what do I still buy? Wired, because I like the ads and graphic layout; "How" (every 6 months or so, same reason), and some non-computer mags. But my magazine budget is not even 10% of what it was 5 years ago.
So supposing I overcome my reluctance of going back 30 years to a command-line development system :-), am I obliged to ship a CD with every unit? Or can I just publish diff files on my website? And where does my advantage go if I publish my source code for my competitors to download, anyway?
Yes, I've read the GPL and the other comments here, but I'm still not sure for this particular case...
It doesn't quite work that way.
These new transistors have much smaller gate thickness, which means less capacitance, which means higher switching speeds, but also a lower breakdown voltage, which means less power. Making the transistors smaller also allows them to be crowded together, which reduces wire length (not necessarily wire thickness, as you think). So the net effect is positive: everything gets smaller and faster and uses less power.
Also these new transistors can be layered one over the other, which is practically impossible with today's horizontal transistors. This also reduces average interconnect lengths. And contrary to what some posters have been surmising, the reduced power requirements balance the greater heat dissipation, so no new cooling techniques are needed.
The self-assembly process isn't understood yet, from what I gather from the article, and it may not be possible to adapt it to patterns more complicated than an array of round pillars - but if it is, you'll get something like a huge matrix of standard blocks. If you figure out the interconnects correctly so they'll self-align, you'll get something which can be programmed by an extension of today's FPGA techniques... either permanently with a laser probe or by injecting serial data streams into the array.
There have been some interesting papers published (sorry, can't find the URL now) about evolutionary programming of FPGA's... that may also be applicable.
Finally, they recently figured out how to make vertical transistors (unlike the horizontal ones used today) which can be stacked in 3 dimensions. So I think we'll see logic and memory chips using these principles in a relatively short time - 5 or 10 years is my guess.
I've followed this subject with great interest for many years. Although I'm not qualified to comment on the fine technical aspects, high-energy particle physics is bound to obey certain time steps... the author is no doubt simply extrapolating from a curve of delivery dates vs. energy of current and planned accelerators, and marking 50 years (plus/minus 50, you will notice) as a likely date when accelerators will reach a certain energy range.
This is the range where he's reasonably confident that there'll be enough significant events to either rule out all but one of the competing theories, or to merge them into one unified theory. At the same time he seems to consider that this is a sufficiently long time for the required mathematical techniques to be worked out, and that enough computing power will be available.
Given that construction times of these accelerators are now over a decade, and likely to get worse they bigger they get - not to speak of the political and financial contortions - his estimate seems quite reasonable.
Consider a parallel situation where most /.ers will have a better feel for things. Suppose you were asked to estimate when 1024-bit (or whatever other magic number you prefer) encryption will be broken. You can estimate the computing power necessary, make an estimate when this will be available by Moore's Law, shave off some years by postulating a cluster of some kind (Beowulf, if you wish ;-)), postulate both a breakdown of Moore's Law at some future time and/or a new technology that goes around that, and so forth. So you'll probably end up with some fuzzy range of so-and-so-many decades. See? If you know the field, it's not so hard.
Then again, if the singularity posited by SF writer Vernor Vinge and cohorts comes around - estimates are somewhere in the 22nd century - everything will be either solved in a very short period of time or declared uninteresting...
Jon, congratulations. Easily one of the best articles I've ever read on /. - have you thought of submitting it to the Whole Earth Review? This theme deserves wide discussion.
I agree... there are two types of "medical software": embedded software for medical instruments, and patient information software. Requirements and processes (and, for that matter, regulatory requirements) are completely different for each...
For over 15 years I've written embedded software for medical devices, and only twice I've found it useful to incorporate source code from outsiders... even so after a very long review and licensing process. For many market segments the only way to outsell competitors is by having better software. I see no future for OSS here at all.
In patient information software the outlook is completely different. Interoperability and security are much more important than proprietary features, so there may be significant opportunities for OSS-based systems.
As it's clear that very few people are still throwing money at "cold fusion" setups, the "hot fusion" variation described in the article seems like the only way to go right now. Once they lick the symmetricity problem - possibly by setting up some positive feedback in the plasma to keep the reaction shape spherical in the crucial nanoseconds - there should be more progress.
Getting parts of the reactor chamber destroyed at every pulse is relatively the easiest part to get around...
and
Texas Instruments is the Intel of the DSP industry, except that they make a better product and don't throw their weight around.
Texas used to be tops at DSP, but AFAIK Motorola has passed them some time ago. Their 56000 series was a huge success and in fact the G4 is an audacious attempt to merge the DSP and MPU lines at the high end - it can run circles around the top TI DSP.
Fe people remember that the G4 was originally launched at NetWorld+InterOp. The demo they had was emulating over 30 V.34 modems on a single G4... not bad at all.
I've always wondered why someone would prefer an internal modem. Everytime an electrical storm hits my town, I hear scare stories of PC users losing their modem cards and motherboards, whereas the Mac users just get their external modems vaporized... now with iMacs selling so well, this kind of thing is starting to happen on the Mac side too. Now that USB modems are coming out, I always recommend external modems for everybody.
If I were to buy a motherboard (with no regard to price), it would have an AGP slot, at least 6 PCI slots, at least 2 EISA/VL slots (for those unfamiliar with the protocol, EISA slots can take ISA cards, and VL slots are a physical extension on the back of an ISA or EISA slot), and at least one preferably two MCA slots.
Sounds like the ideal system for a hardware hacker/developer (although even a developer nowadays probably wouldn't be doing stuff for legacy systems). For software developers or plain users, the simpler the system, the better...
Allow me to disagree somewhat with this paragraph only... unless you're talking about these new embedded servers which are starting to appear. In those, one's not concerned about performance, it's sufficient to get your little box actually serving pages out to the net. Portability's not important either for embedded servers; code compactness perhaps, as memory is always limited.
For real-world servers writings CGIs in Java is an easy way to get things rolling, but performance-wise they just don't cut it, and you get an extra layer of software where bugs may creep in.
For non-server embedded systems, I wouldn't trust Java in the foreseeable future to meet real-time scheduling requirements... and who needs portable embedded code, for that matter? Most embedded designers don't trust anything they don't have full source code for. How would you go about debugging a Java embedded system with a data analyzer, anyway? Just the thought makes me queasy...
All this periodic hoo-haa about interpreted languages leaves me cold... there are cycles where they surface and go under again without a trace. IBM's RPG and UCSD p-code were early examples. Middle-period Microsoft apps were partially interpreted, and good riddance! Forth is about the only interpreted language I'd use in an embedded system - I've written a few interpreters for that myself. Even so, it takes care and optimization for each case.
An enormous penguin, rendered with ASCII in various colors, parts of the statue are unfinished at certain points, allowing one to glimpse Linus-faced figures inside, frantically typing at (obviously mouse-less) terminals.
Around the statue, masses of mindless /.ers kowtow and offer sacrifice...
A tunnel is shown being dug underneath the idol, with Gates-faced sappers readying dynamite charges.
At one side, a puzzled user is being interviewed by a reporter, asking "...but does it run WordStar?"
Any coincidence is just a resemblance ;-)
It's decades old, in fact. When I was debugging patches to DOS/360 and OS/360 (for IBM mainframes) and MCP (for Burroughs mainframes) a core dump, directed to the high-speed printer, was an invaluable tool.
Once RAM sizes passed the megabyte mark, the effectiveness was much reduced; it was just too much paper to page through. There was enough hardware information (3 extra tag bits for each 48-bit word) to allow the MCP core dump to be formatted into data, code, and stack areas. The IBM dumps were tough going to decode. On a modern microcomputer, of course, lots of other things like page tables and registers have to printed out, too...
Frankly, I was puzzled by this reference to petroleum-generating dinosaurs, all previous literature on the subject - at least what I've read - emphasized plant mass as the presumed source for petroleum.
A little thinking, also, will show that the total biomass for dinosaurs, or any animals even, (not considering the "era") must have been insignificant compared to that of plants or even microorganisms or insects, as is still the case today.
IMHO Gold may well be right in principles, although wrong in some particulars. The original "cambrian biomass" theory for oil/petroleum is quite dated and has suffered little revision... hydrocarbons are known to occur in great quantities elsewhere in the universe, and a layer of hydrocarbons in the Earth would certainly be hospitable to life. Life can potentially be found at any energy gradient, as the example of deep-sea hot spots shows.
I'm impressed.
This sentence caught my eye too... impressive, but not unheard of.
In fact, several excellent teachers I've had told me similar stories. IIRC even such luminaries as Richard Feynman had to do this sort of thing on occasion... the combination of extreme time pressure and the memories of very recent learning can help to produce a very successful teaching experience. Can lead to ulcers, though...
As a part-time embedded systems designer, I routinely have to consider both hardware and software issues. And in my estimate the mental models one builds based on some knowledge about both sides of the "science" help a lot with solutions design.
Regarding the book itself, I've skimmed through the version published on the web. Although a few parts are somewhat dated, it's seems to be quite useful for teaching principles. In the real world things aren't as clear-cut of course; I spend much more time ferreting out race conditions, worrying about shielding, decoupling and board layout, power supply ripple specs and so forth, rather than designing finite state machines. I've yet to see a textbook that addresses these issues in a useful way... let alone the hardware/software interactions.
For instance, consider something like a Palm Pilot. It's in sleep mode, and when you press a key, it wakes up and an interrupt routine is executed, which then does whatever the key means. On waking up, you get a huge power spike - the CPU's power consumption increases a thousandfold inside a few microseconds - and if the board designer hasn't allowed for that, when the power spike bounces back down the interrupt routine may crash. The programmer can stare at a source listing or emulator trace for months with no progress at all unless he knows about such hardware details.
I haven't seen demographics about the "slashdot crowd", but my impression is that perhaps half are quite young - they haven't messed around with valve radios or Heathkits before taking up programming [insert half-senile chuckle here]. Well, the hardware side of the business has progressed a lot - perhaps even more than the software side - since I started out 30 years ago... my advice to everybody is to take some time to study up on what's happening on the other side of the fence, it's worth it.
That's perfectly doable if the 5-10% were separated at birth, so to speak, from the 90-95%. In other words, if the software (game or not) were specifically developed from the beginning for a cross-platform destiny... in practice, everything is so intertwined that you're better off throwing 50-60% of the code away and rewriting it from scratch.
This can usually be done only by the original programmers - I doubt that a subcontractor (as was the case here) would succeed. I've done a few Windows-to-Mac ports (not games) and the way the originals were written, less than 40% were usable in one case, the others needed a from-the-ground-up rewrite. Of course, the marketing/accounting guys think this is outrageous and never budget for that, as it may take nearly as much time and money as it did for the original. So much for calling it a "port".
I find it hard to belive that a small company like Id somehow has the resoueces and programming competancey to release all three versions of a game SIMULTANEOUSLY (as Carmack has promised to do with Q3), whilst a gigantic company like Sierra can't come up with the resources or programming skill to release seperate versions at all!?!?!?
Welcome to the real world. The larger a company is, the less agility they have for this sort of thing... there's an optimum size for doing this and Id seems to have hit that sweet spot. If they put in more people the extra guys would just be stepping on each other's toes and spend their time writing interdepartment memos.
Seems to me, that given the minimal necessary effort (unless my recollection of Carmack's .plan is REALLY fuzzy, or he was lieing) to convert a game, and the potential for easy money; the only reason a game would NOT be released simultaneously for windoze, Linux, and Macintosh, is purely political.
I agree to a certain extent, but I'd consider internal politics as the culprit rather than postulate a "Seattle Conspiracy". My experience is that porting software once it's been released is an uphill battle against factions which don't want to commit significant resources to what they think is "only a quick port". Successful cross-platform apps are done in-house by very experienced teams and all at the same time. Period. Getting an external contractor do it later is foolhardy.
Quite possibly the best first chapter in recent SF. Heck, make that the best first page ever! People complain about the ending, but I frankly can't even remember what the ending is... anybody who can write a first page like that can be forgiven any ending whatsoever.
And of course, the book practices what it preaches - the first page is a virus carrier for selling further copies of the book. I may have helped sell over 20 copies just by ordering people to "read this!" in a bookstore.
Despite later comments in this thread, why would he throw in the "chiseled spam" comment if they weren't the same person - or analogues in parallel universes?
But I second (or n+1nd) the motion for a Neal Stephenson interview. My question would be when "Spew", previewed years ago in Wired, hasn't come out yet...
Use uClinux for your product insted.
http://www.uClinux.org
http://www.uClinux.com
D. Jeff Dionne
I've e-mailed them (or should I say, you? ;-) a couple of times, nobody replied - the website hasn't been updated for several months - the mailing list archives are ancient. I thought the project had been cancelled, in fact.
Would you have an URL for downloading the full uClinux source? The link I saw on the website only leads to a couple of diff files - not very practical for me.
Regarding the 256-color capability, it was about time. It's getting hard to specify the 16-level grayscale LCDs that were supported in the EZ, most manufacturers are abandoning them.
Does anyone in the audience have experience with Motorola's PPSM operating system for the DragonBall? I'd like to try it, but their website is mum about licensing details...
I have both of her books, which are indeed excellent... although I'm usually uncomfortable with the adoption of the split-brain concept by pop/amateur psychologists.
Specifically in programming, whether algorithm design or actual coding, I think both hemispheres, or one might say more accurately, both verbal and non-verbal processes are involved. While the actual hierarchical structuring is essentially non-verbal, at the same time much attention must be paid to verbal fields like naming of variables, programming language syntax, typing... even visual program layout isn't completely non-verbal. Though E.R. comments:
Coding, I believe, is a conceptual task like drawing, not a verbal one, despite being built up of little words like "while" and "if." When in Deep Hack Mode, one considers "while" as a programmatic concept, not a word, and the movements necessary to convey that concept (typing) are performed out of rote rather than requiring verbal concentration. A skilled musician may experience the same thing...the names and durations of the individual notes are no longer something to be concentrated on while playing...the body is "tuned" to carry them out and string them together as an act of continuous non-verbal expression.
Allow me to suggest that this isn't necessarily a valid analogy, as recent research seems to indicate that this sort of extremely skilled motor activity actually involves learning by the spinal neurons; that is, the "macros" are more in the firmware than in the software, if one can say that. Furthermore, I doubt that typing a word like "while" automatically as if it were a chord is as disconnected from verbality as is playing a chord on the piano... after all, you're reading it while typing it, and need visual feedback to see if it's typed correctly. And if you're not a native English speaker, you actually need to be even more attentive...
Allow me to add Steve Reich's "Music for 18 Musicians" and anything by Penguin Cafe Orchestra to that list.
I know Reich, never heard of the P.C.O. Thanks for the tip - I'll look them/he/she/it up. I also forgot to mention one of the grandfathers of minimalism, Terry Riley. His classic "In C" was reissued recently. You may also like the "Tibetan Bells" records and early Kraftwerk.
Well, I notice that lots of people are simply posting their preferences without going into considerations why music helps with coding (or indeed most creative activity). FWIW, my own preferences are Philip Glass, Weather Report, John Coltrane, Jan Garbarek, David Darling, Keith Jarrett, some Pink Floyds, and new age/ethnic stuff like Uakti, Don Harriss and early Jean-Michel Jarre.
Notice that none of these have words - I occasionally listen to Joni Mitchell too, because the melody is sufficiently complex to override voice recognition. There's a very interesting book by Ray Jackendoff, "Consciousness and the Computational Mind" (currently unfortunately out of print, but any university library should have it). Jackendoff is both a linguist and a musician and has many interesting insights about the similarities between music and language - listening to wordless music is like listening to poetry in a foreign language, in his view, as the semantic part of language processing is shut out and you just do the lower-level phonetic and syntax processing - sound and rhythm.
As to why this should help coding, I'd say that the way music is structured - several levels of hierarchy, loops, variations on a theme, macros, and so forth - parallels mental models of software. Therefore the same neuron clusters should be involved, and there would be no conflict in doing both at the same time.
I also conjecture that nearly everybody listens to CDs, and not radio - since you already know the records, there are no surprises and the repetition actually stimulates you to create new patterns in your coding.