That's funny, I was about to suggest that people instead just install the latest release of NetBeans 6.0. It comes with Ruby and the Rails packages (including webrick) installed by default. Of course, this won't work if you don't have Java installed, but if you do have something relatively recent (Java 1.5 or later), then it's pretty painless to get it up and running.
Actually, I think the author got it backwards: the VT-100 was the first terminal to support more than 80 columns. At least, it was the first one I ever saw. Most of the terminals we had around that time (evil ADM-3s and -5s, MiME-1s, VT-52s and those beautiful but useless Tek 4010/4014s[0]) would do the standard 80x24/25, and several sported "enhanced" character sets (bold, blinking, underlined, double-wide, etc.). The (DataMedia?) DT-80 was a VT-100 clone and supported 132 columns too. Oh, and soft scroll, I loved that. Useless when trying to get any real work done, but it looked so elegant when you were scrolling through a program listing or report.
[0] They were bit-addressable video graphics terminals, and didn't scroll. So whenever you hit return on the bottom line, the cursor would just wrap around to the top line and print over whatever was already displayed, so you had to keep smacking the Clear button. Especially amusing when you make a typo in your source and the compiler spits out ten screenfuls of errors...
It just shows that it's easier to copy, than to create. Yeah, that was my thought too. Their development speed is impressive, but that's what a bunch of cowboys can do. No requirements beyond "implement this spec", no design artifacts, probably no formal Q/A or test suite. It's fun to crank out the code when somebody else has done the hard part of specifying and designing it already! I'd be much more interested in what they could come up with if they'd started with the same list of feature requirement that the Silverlight team did, and see what solution they could come up with.
every federal prosecutor and his brother will be jumping at the chance to head up the anti-trust suit Yes, since that worked so well the last time...
Court: "Microsoft, you've been found guilty of anti-competitive and monopolistic practices. What do you have to say for yourself?" Microsoft looks at the floor, hands in pockets, mumbles "Sorry...." Court: "Well, don't let it happen again!"
the extremely obvious wires holding up the spinner in several scenes *snort* C'mon, those were obviously a phased-array antenna system for their UltraSuperMegaStreetFighterTurboDefinition 1:4:9 phase-conjugate audio/video/tactio deck. Everybody's got those in the future. Everybody who's anybody, anyway.
you're elite and run *BSD Oh yeah, 4ssh0l3 BSD. I've heard really good things about it, but the only guy I know who runs it just gave me a photocopy of the CD when I asked for a copy of the installation disk...
IBM--no other company has the wherewithal or money to get the job done. I wouldn't count TSMC or UMC out of the running. Both have SOTA fabs and plenty of capacity. If AMD wanted to partner with either one, I'm sure they'd step up to the plate. And don't neglect the effort that China is making to get semiconductor companies to build fabs over there. Intel's putting one in, and ST-Hynix is already cranking out 300mm wafers from their new Wuxi plant. I'd wager that if AMD's seriously considering outsourcing their production, they've already determined that there are multiple suppliers who could provide the service.
Anybody else remember the one with the two vultures on it that said "Scavengers my eye! I'm going to kill something!" I imagine a Beowulf cluster of these would look like a swarm of pirhanas come feeding time...
Bill Joy, "probably" brought over a lot of the code from the Berkeley distribution Seems fair, insofar as he wrote a goodly chunk of it. After all, he was the one who assembled and distributed the release tapes for 1BSD (a large set of patches for Sixth Edition Unix), wrote the ex editor and the C shell for 2BSD, wrote the widely-copied TCP/IP stack for 4.1BSD, and also created NFS and vi (maybe you've heard of them). The impression I get is that he was the de-facto leader of the CSRG until he left to co-found Sun. We started using 4.2BSD in '82, and IIRC all we had to do was get a source license from AT&T (~US$500) for those few modules that CSRG hadn't rewritten. Everything else was (of course) under the BSD license...
78s are very breakable, like a dinner plate. They were actually made from shellac and lampblack. I've seen a couple of furniture refinishing shows on TV where they took old broken 78s and stuck them in a jar with some denatured alcohol and used the results to produce a "classic finish" on some old furniture.
Especially when you consider how many pictures are taken in bars and at parties and other low-light locations. If somebody's got a real camera, they typically have a decent flash and know when to use it. It's when you're trying to snag some cutie's pic to store along with her number in your phone that you have trouble.
RAM must be slowed to be recorded Um....what? Recording IP addresses might affect your throughput, but it won't have any effect on your memory cycle time. Unless you're proposing using some kind of bus analyzer to capture every state change. Which (given the difficulty of reconstructing the data) would probably get you slapped with a contempt charge....
with experience, you come to write fairly optimized code the first time through and the additional time spent profiling and refactoring isn't worth the effort if an experienced coder has done his job right Quite right, and that's what I was getting at when I mentioned that a profiler allowed you to learn what optimization techniques worked best. Especially once you've gone through that first marathon optimization session, where you need to speed up your code by an order of magnitude or so. You take such things as lazy initialization, prefetching and caching to heart pretty quickly.
GP was spot on, too — profiling and optimization are to be done once your code already works, not during initial development. That allows you to create test cases you can use for regression testing during optimization. And it's surprising how little doing things in a straightforward fashion costs you, performance-wise, most of the time. I pretty much always write simple, easy-to-follow code anymore since (as someone else alluded to) most of my systems' run time gets eaten up in O/R mappers and other abstraction layers. Factor that in with the accrued latency due to remote database servers and web service calls, and the actual improvement you can get from efficient code becomes a pretty small part of the equation. That's why I enjoy the systems architecture part of my job, I have more control over the things that really affect performance nowadays.
Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong.
A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.
I can't believe people pay Gartner for this stuff. Heh, pick up a copy of anything by Tom Peters or his ilk. People who buy those books also pay money for Gartner analysis reports. At least Tom Peters came right out and said that he had no idea what he was talking about when he wrote his first book. I think it's going to take a lot of people screaming "The analysts have no clothes!" (clues?) before people start questioning Gartner, though.
The problem with this ideology is that most people aren't tech-savvy enough to learn the principles of a piece of software and adapt to different vendors. Perhaps I've just been lucky, but I haven't found this to be true. Most of the secretaries/PAs/front-office staff I've worked with have always been focused on Getting The Job Done, and they really couldn't care less about what tool they use, as long as it works and doesn't make them jump through hoops. My first job was with a non-profit, and we had a random collection of software that was either donated or purchased for evaluation. So while the standard WP was DisplayWrite (yes, this was shortly after fire was discovered), we had one machine with Word, three with WordPerfect, and all of our regional offices had Kaypro CP/M machines with WordStar. And all the office staff knew how to get their jobs done with each one of them. Of course, we didn't use a lot of the more involved functions (anything beyond a ToC was pretty 1337), but everybody knew how to set margins and format a table and set their justification and everything else they needed to do their job.
Most office-type software has enough help features (tooltips, F1 for context-sensitive help, help menus) that anyone who knows what functions should be present shouldn't have much trouble figuring out how to make any program do what they want. The problem is people who don't really think about what they want, they "just always do File->Fold->Mangle->Masticate and it does it".
it has only Fw400 which limits your external expansion options Really? What are you looking for that it hasn't got? eSATA? SCSI? FC? From what I've heard (anecdotal evidence FTW!), FW *is* faster than USB2.0 for large (>500MB) file transfers, but for most applications an external USB HD would be fine (better, probably, since it'd be 7200RPM vs. the 5400RPM internal drive). I know I can get to my files faster from my external (USB) HD than I can from the internal HD in my Thinkpad, anyway.
(SuitSat1 was a worn-out Orlan [Russian space suit] with some batteries and a transmitter inside that the ISS crew literally kicked out the door. You could hear it transmitting its internal temperature, battery power and 'elapsed mission time' on the 2M band.)
Heh, that was my first thought: "Jesus, how soon before I see these things stomping around Wal-Mart?" I swear, I go there about five times a year, and every time it's like Bloated Freaks on Wheels week.
I wouldn't be surprised if the original design was predicated on using chips that actually met their published spec (QC wasn't as tight a QC ago...). That design was pretty spare, I'll bet it didn't have a lot of timing tolerance. One way to "fix" such problems is to add some more gates (= more gate delay), which flew in the face of Woz's design goal of minimizing the overall chip count.
There also could have been some problems that cropped up when (if) they had to redesign the board layout for production. Doesn't mean the design was bad, just that it wasn't tested in the final configuration. Fixing those kinds of problems is a production engineer's job, and blaming it on R&D's "poor design" is a cop-out.
Exactly my experience. I didn't know Electric Fence existed (and it may not have, this was back in '92-'93), so I wrote my own malloc replacement with bounds checking. It didn't eat up much more memory (I think around 64 bytes/allocation) or use a whole lot of CPU (basically, it walked the heap checking for corruption every N allocations, and N was configurable down to 1).
I still remember the first time I tested it; I allocated some memory, then dumped the heap. I saw the block I had allocated, but there was another 2K block allocated that I hadn't! Fortunately I was dumping the contents along with the size, and I quickly figured out that printf() was calling my allocator too! (I had written replacements for [mc]alloc() and free(), and used the same names so I could instrument existing code w/o having to rewrite it.)
I can't promise we'll fire the person I hope you don't — as I explained elsewhere, I think the content was fine, it just needed to be cleaned up before it went out, and I don't think that is the engineer's responsibility. I just hope whoever posted it to the support web site comes in tomorrow and thinks "Something's bugging me about that TBB page, I'm just going to take a quick look and make sure..." and realizes they published the original copy instead of the official version.
Slashdot Mirror
That's funny, I was about to suggest that people instead just install the latest release of NetBeans 6.0. It comes with Ruby and the Rails packages (including webrick) installed by default. Of course, this won't work if you don't have Java installed, but if you do have something relatively recent (Java 1.5 or later), then it's pretty painless to get it up and running.
Actually, I think the author got it backwards: the VT-100 was the first terminal to support more than 80 columns. At least, it was the first one I ever saw. Most of the terminals we had around that time (evil ADM-3s and -5s, MiME-1s, VT-52s and those beautiful but useless Tek 4010/4014s[0]) would do the standard 80x24/25, and several sported "enhanced" character sets (bold, blinking, underlined, double-wide, etc.). The (DataMedia?) DT-80 was a VT-100 clone and supported 132 columns too. Oh, and soft scroll, I loved that. Useless when trying to get any real work done, but it looked so elegant when you were scrolling through a program listing or report.
[0] They were bit-addressable video graphics terminals, and didn't scroll. So whenever you hit return on the bottom line, the cursor would just wrap around to the top line and print over whatever was already displayed, so you had to keep smacking the Clear button. Especially amusing when you make a typo in your source and the compiler spits out ten screenfuls of errors...
Court: "Microsoft, you've been found guilty of anti-competitive and monopolistic practices. What do you have to say for yourself?"
Microsoft looks at the floor, hands in pockets, mumbles "Sorry...."
Court: "Well, don't let it happen again!"
I know! Let's stand him on his head!
There, you see — it's morning!
Anybody else remember the one with the two vultures on it that said "Scavengers my eye! I'm going to kill something!" I imagine a Beowulf cluster of these would look like a swarm of pirhanas come feeding time...
Especially when you consider how many pictures are taken in bars and at parties and other low-light locations. If somebody's got a real camera, they typically have a decent flash and know when to use it. It's when you're trying to snag some cutie's pic to store along with her number in your phone that you have trouble.
Remind me not to have contact with you....
GP was spot on, too — profiling and optimization are to be done once your code already works, not during initial development. That allows you to create test cases you can use for regression testing during optimization. And it's surprising how little doing things in a straightforward fashion costs you, performance-wise, most of the time. I pretty much always write simple, easy-to-follow code anymore since (as someone else alluded to) most of my systems' run time gets eaten up in O/R mappers and other abstraction layers. Factor that in with the accrued latency due to remote database servers and web service calls, and the actual improvement you can get from efficient code becomes a pretty small part of the equation. That's why I enjoy the systems architecture part of my job, I have more control over the things that really affect performance nowadays.
Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong.
A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.
Likewise, NetBeans does C/C++ and Ruby.
Most office-type software has enough help features (tooltips, F1 for context-sensitive help, help menus) that anyone who knows what functions should be present shouldn't have much trouble figuring out how to make any program do what they want. The problem is people who don't really think about what they want, they "just always do File->Fold->Mangle->Masticate and it does it".
...soon we'll have more SuitSats to listen for!
(SuitSat1 was a worn-out Orlan [Russian space suit] with some batteries and a transmitter inside that the ISS crew literally kicked out the door. You could hear it transmitting its internal temperature, battery power and 'elapsed mission time' on the 2M band.)
Heh, that was my first thought: "Jesus, how soon before I see these things stomping around Wal-Mart?" I swear, I go there about five times a year, and every time it's like Bloated Freaks on Wheels week.
I wouldn't be surprised if the original design was predicated on using chips that actually met their published spec (QC wasn't as tight a QC ago...). That design was pretty spare, I'll bet it didn't have a lot of timing tolerance. One way to "fix" such problems is to add some more gates (= more gate delay), which flew in the face of Woz's design goal of minimizing the overall chip count.
There also could have been some problems that cropped up when (if) they had to redesign the board layout for production. Doesn't mean the design was bad, just that it wasn't tested in the final configuration. Fixing those kinds of problems is a production engineer's job, and blaming it on R&D's "poor design" is a cop-out.
Exactly my experience. I didn't know Electric Fence existed (and it may not have, this was back in '92-'93), so I wrote my own malloc replacement with bounds checking. It didn't eat up much more memory (I think around 64 bytes/allocation) or use a whole lot of CPU (basically, it walked the heap checking for corruption every N allocations, and N was configurable down to 1).
I still remember the first time I tested it; I allocated some memory, then dumped the heap. I saw the block I had allocated, but there was another 2K block allocated that I hadn't! Fortunately I was dumping the contents along with the size, and I quickly figured out that printf() was calling my allocator too! (I had written replacements for [mc]alloc() and free(), and used the same names so I could instrument existing code w/o having to rewrite it.)