Ummm, what? Since when? Is this some/. 31337-ness? Linux is as much Unix as Solaris, AIX, or the BSDs. Yeah, it's a different kernel: they all have different kernels. But they all follow the Unix design philosophy (everything's a file, files are streams of bytes, etc.)
Sounds like they sucked his brain out and poured MS oatmeal in the hole. From TFA:
Daniel Robbins has decided to leave Microsoft to pursue his passion for software development with an independent software vendor where he will be focused on building in.NET on Windows.
I remember VMS had a decent approach to that. Something like, if your process was idle for more than a few seconds, it would temporarily raise the priority (after all, you're not doing anything, so it's free). Then, once your process woke up, it would degrade the priority back to its assigned level. All normal tasks ran at priority 4, but if you were in the editor and not typing, your priority might get bumped up to a six. Someone else's compile might be soaking up 100% of the CPU, but as soon as you hit a key, you got priority. By the time you'd entered half a line or so, your priority was back down to 4 and you were slogging it out with the compiler job, but initially you got pretty much instant response, which told you that the machine wasn't wedged.
With multiple cores, you need software able to use these cores,
Not necessarily, which is to say, not at all. If all you use your computer for is one CPU-intensive thing (games or rendering or Mathematica), then yes you won't get all the benefit. But computers today run so many tasks simultaneously (one per window, plus init, swapper, inetd, cron, lockd, statd, X server, plus whatever else you're doing) that you'll get some benefit regardless what you run. I still have issues occasionally when my XP box at work will freeze when the network gets loaded. With a true multi-core (none of this HT stuff) or multi-CPU box, you'll at least be able to fire up a shell (or the Task Manager) and find out why something's so slow.
Not gonna happen. You know why? Because of Marc, Gavin King and their pet toad Bill Burke. When I think Weblogic, I think quality software. When I think of Websphere, I think Tomcat with a load of cruft bolted to every exposed surface. When I think of JBoss, I think arrogant poseurs with an app server. Face it, JBoss is more about the players than the product, and that's never going to cut it in the Real World. They've done remarkably well, but they're basically a fly buzzing around the real players. And, like a fly, if they ever become too annoying, they'll get swatted. Or maybe this is what Oracle is doing, setting out a pretty sundew plant...
My first machine only had 4K of memory. When I got the 16K upgrade, I was in paradise! Well, just outside paradise, anyway -- still had to save and restore to cassette tape.
And if it weren't for this obsession with GUIs and VMs, 64K would still be a useful amount of space today!
Intel made design choices that made the hardware itself very challenging
You misspelled "HP". Itanium was originally going to be the new PA-RISC chip, (originally named 'PA-WideWord'). HP approached Intel when it became apparent that they wouldn't produce the volume of chips to make it profitable to upgrade their fab (which they would have to do to produce a chip of Itanium's complexity). So, enter Intel ca. 1994. Sun produced a version of Solaris for the new chip, IBM and SCO played together nicely (along with Sequent) to produce a version of Unix they called Monterey, Compaq ported Tru64, and SGI actually went so far as to announce they were going to drop MIPS altogether to support it.
And now the wheel has turned, and we're in a brand new x86 world. Itanium was late, SGI forced another couple of generations out of MIPS, and AMD showed Intel how x86 was done. Sun dropped Solaris/Itanium in 2000, IBM and Dell have both dropped their Itanium lines, and Microsoft has announced support for Itanium in Longhorn.
It's a hell of a paradigm shift for programmers to go from writing code that targets one CPU to code that deliberately splinters tasks across a bank of specialized processors.
Not really, developers have been using co-processors for years -- numeric (a la Weitek or 8087), DSP, odd-wad AI and "dataflow" boxes. And I imagine the early attempts will follow a similar pattern: present the functionality of the co-pro wrapped neatly in a library, then just call the library routines. Presto, your code is automatically vectored to the other unit, and you can either wait synchronously or specify either a callback routine or an event flag to set when the call completes.
Of course, as the techniques get explored in more depth, and developers start to chafe at the restrictions of the library model, then people will start writing in-line code, or writing code to be loaded directly onto the specialized processors and communicating with the main-line code via specific protocols. Frankly, it's more of the same-old, same-old, hardly a "paradigm shift" -- unless you haven't seen it before.
having 4 workspaces is exactly what people with 20+ apps open need
No, people with 20+ apps open need four monitors. Trust me, once you go dual-head, you never look back (or need to -- just put a reverse view on the other monitor...;)
Seriously, my productivity increased probably a good 20% or so once I was able to keep my full-screen IDE on one monitor and a full-size display of the current spec on the other. No more flipping through thirty or forty pages of printout to find a definition while coding a use case, no more minimizing or maximizing or tiling, just throw an app on a monitor and use it.
Unfortunately, I had already taken a pay cut (~11%) to work closer to home (traded a one hour commute for a ten minute one, applied the saved time directly to my family). It would have been another 10% drop in pay, and I didn't think the work was that interesting!
/me flashes back to the day, when I was one of sixty-four CS students editing, compiling and testing on a single VAX running VMS. With one (1) megabyte of memory. That's right, dear friends, roughly a quarter of the cache of your average disk drive today. Makes me wonder how much memory my box would use if I killed X and ran everything from the console...
I have an Ultra 20 with the nVidia NVS540 card. It seems to work pretty well, but I don't really do a lot of graphically-intensive work, and I've never used a generic driver, so I can't guess what the speedup is. I'm not sure what you're looking for, quality-wise: getting the absolute best performance, or no noticable bugs? The graphics were snappier under CDE than the (GNOME-based) Java Desktop System, but then again CDE is, what, ten years old? (It looks unchanged from the version I used on HP/Apollo workstations in the mid-90s.) I imagine it puts a lot less stress on the GPU.
And when it comes, there'll be a mad rush for 64-bit boxes, and everyone'll be wishing they'd made the jump sooner. Face it, it's only a matter of time, and time runs pretty fast in this business. Might as well get your bitness on now, so you can complain about how slow your computer runs the newest stuff, instead of complaining about how it won't run it at all.
Verizon refuses to tell you what bandwidth you can get until you order a phone line from them
Until they know the distance from the CO, they can't really tell what the line attentuation is going to be, so they don't really have any idea what the speed will be. And if you're farther than ~13K ft, it's not likely they can provide *any* level of service.
Personally, I'm switching to Alltel DSL this weekend (allegedly 1.5/256). We'll see how it goes, I'm not turning off my 3M/256 cable modem until I'm satisfied with the throughput.
Probably more due to the fact that Java apps tend to be big -- not because Java is "bloated", but because Java's OO-nature makes it easier to write large apps. I've written little command-line utilities that don't take appreciably longer to start than others written in C. Large apps like ArgoUML may take longer to start, but once you're in them you're there for a couple of hours, so an extra ten seconds or so on the front end really isn't going to make any difference.
I'd have to go with the VB crowd. First off, any reasonably recent (since WinME) version of Windows will already have the VB runtime installed. Plus, VB (at least as of version 5, which is the last version I used) has a built-in installer builder/packager. Once the app is done, you just identify the files it uses (in his case, probably one.frx and maybe a third-party control to read the serial port), then push a button and it spits out a ready-to-distribute installer. It's no InstallSheild, but it's perfect for this project.
Nothing against Tcl (actually, I hate it, but this would be a good application for it), but apps built against Tk don't look quite like Windows apps. Not sure if that would be a factor, but the principle of least astonishment would seem to apply here.
Slashdot Mirror
Linux is not UNIX
/. 31337-ness? Linux is as much Unix as Solaris, AIX, or the BSDs. Yeah, it's a different kernel: they all have different kernels. But they all follow the Unix design philosophy (everything's a file, files are streams of bytes, etc.)
Ummm, what? Since when? Is this some
What next, Ubuntu/Red Hat/SuSE's not Linux?
resistance heat is 100% efficient
Yeah, that was our slogan when I was in the resistance...
I can't believe no Ellison stories were mentioned. His script for I, Robot was just amazing.
Sounds like they sucked his brain out and poured MS oatmeal in the hole. From TFA:
.NET on Windows.
Daniel Robbins has decided to leave Microsoft to pursue his passion for software development with an independent software vendor where he will be focused on building in
what would all that pr0n look like in reverse?
Everybody goes to church and votes Republican?
I remember VMS had a decent approach to that. Something like, if your process was idle for more than a few seconds, it would temporarily raise the priority (after all, you're not doing anything, so it's free). Then, once your process woke up, it would degrade the priority back to its assigned level. All normal tasks ran at priority 4, but if you were in the editor and not typing, your priority might get bumped up to a six. Someone else's compile might be soaking up 100% of the CPU, but as soon as you hit a key, you got priority. By the time you'd entered half a line or so, your priority was back down to 4 and you were slogging it out with the compiler job, but initially you got pretty much instant response, which told you that the machine wasn't wedged.
With multiple cores, you need software able to use these cores,
Not necessarily, which is to say, not at all. If all you use your computer for is one CPU-intensive thing (games or rendering or Mathematica), then yes you won't get all the benefit. But computers today run so many tasks simultaneously (one per window, plus init, swapper, inetd, cron, lockd, statd, X server, plus whatever else you're doing) that you'll get some benefit regardless what you run. I still have issues occasionally when my XP box at work will freeze when the network gets loaded. With a true multi-core (none of this HT stuff) or multi-CPU box, you'll at least be able to fire up a shell (or the Task Manager) and find out why something's so slow.
Not gonna happen. You know why? Because of Marc, Gavin King and their pet toad Bill Burke. When I think Weblogic, I think quality software. When I think of Websphere, I think Tomcat with a load of cruft bolted to every exposed surface. When I think of JBoss, I think arrogant poseurs with an app server. Face it, JBoss is more about the players than the product, and that's never going to cut it in the Real World. They've done remarkably well, but they're basically a fly buzzing around the real players. And, like a fly, if they ever become too annoying, they'll get swatted. Or maybe this is what Oracle is doing, setting out a pretty sundew plant...
My first machine only had 4K of memory. When I got the 16K upgrade, I was in paradise! Well, just outside paradise, anyway -- still had to save and restore to cassette tape.
And if it weren't for this obsession with GUIs and VMs, 64K would still be a useful amount of space today!
</OldePh4rt>
Intel made design choices that made the hardware itself very challenging
You misspelled "HP". Itanium was originally going to be the new PA-RISC chip, (originally named 'PA-WideWord'). HP approached Intel when it became apparent that they wouldn't produce the volume of chips to make it profitable to upgrade their fab (which they would have to do to produce a chip of Itanium's complexity). So, enter Intel ca. 1994. Sun produced a version of Solaris for the new chip, IBM and SCO played together nicely (along with Sequent) to produce a version of Unix they called Monterey, Compaq ported Tru64, and SGI actually went so far as to announce they were going to drop MIPS altogether to support it.
And now the wheel has turned, and we're in a brand new x86 world. Itanium was late, SGI forced another couple of generations out of MIPS, and AMD showed Intel how x86 was done. Sun dropped Solaris/Itanium in 2000, IBM and Dell have both dropped their Itanium lines, and Microsoft has announced support for Itanium in Longhorn.
It's a hell of a paradigm shift for programmers to go from writing code that targets one CPU to code that deliberately splinters tasks across a bank of specialized processors.
Not really, developers have been using co-processors for years -- numeric (a la Weitek or 8087), DSP, odd-wad AI and "dataflow" boxes. And I imagine the early attempts will follow a similar pattern: present the functionality of the co-pro wrapped neatly in a library, then just call the library routines. Presto, your code is automatically vectored to the other unit, and you can either wait synchronously or specify either a callback routine or an event flag to set when the call completes.
Of course, as the techniques get explored in more depth, and developers start to chafe at the restrictions of the library model, then people will start writing in-line code, or writing code to be loaded directly onto the specialized processors and communicating with the main-line code via specific protocols. Frankly, it's more of the same-old, same-old, hardly a "paradigm shift" -- unless you haven't seen it before.
I thought these cartoons were first published back in September. It's surprising that it only took four months for people to start whacking websites?
having 4 workspaces is exactly what people with 20+ apps open need
;)
No, people with 20+ apps open need four monitors. Trust me, once you go dual-head, you never look back (or need to -- just put a reverse view on the other monitor...
Seriously, my productivity increased probably a good 20% or so once I was able to keep my full-screen IDE on one monitor and a full-size display of the current spec on the other. No more flipping through thirty or forty pages of printout to find a definition while coding a use case, no more minimizing or maximizing or tiling, just throw an app on a monitor and use it.
Security clearance? For a PR position? Doubtful. It's not like they're going to be issuing press releases regarding their top-secret research.
Unfortunately, I had already taken a pay cut (~11%) to work closer to home (traded a one hour commute for a ten minute one, applied the saved time directly to my family). It would have been another 10% drop in pay, and I didn't think the work was that interesting!
/me flashes back to the day, when I was one of sixty-four CS students editing, compiling and testing on a single VAX running VMS. With one (1) megabyte of memory. That's right, dear friends, roughly a quarter of the cache of your average disk drive today. Makes me wonder how much memory my box would use if I killed X and ran everything from the console...
I have an Ultra 20 with the nVidia NVS540 card. It seems to work pretty well, but I don't really do a lot of graphically-intensive work, and I've never used a generic driver, so I can't guess what the speedup is. I'm not sure what you're looking for, quality-wise: getting the absolute best performance, or no noticable bugs? The graphics were snappier under CDE than the (GNOME-based) Java Desktop System, but then again CDE is, what, ten years old? (It looks unchanged from the version I used on HP/Apollo workstations in the mid-90s.) I imagine it puts a lot less stress on the GPU.
I've yet to see a killer app for 64-bit.
And when it comes, there'll be a mad rush for 64-bit boxes, and everyone'll be wishing they'd made the jump sooner. Face it, it's only a matter of time, and time runs pretty fast in this business. Might as well get your bitness on now, so you can complain about how slow your computer runs the newest stuff, instead of complaining about how it won't run it at all.
Verizon refuses to tell you what bandwidth you can get until you order a phone line from them
Until they know the distance from the CO, they can't really tell what the line attentuation is going to be, so they don't really have any idea what the speed will be. And if you're farther than ~13K ft, it's not likely they can provide *any* level of service.
Personally, I'm switching to Alltel DSL this weekend (allegedly 1.5/256). We'll see how it goes, I'm not turning off my 3M/256 cable modem until I'm satisfied with the throughput.
If you call them, they'll know you can hear! Unless you were going to call them and just repeat "What?" everytime they spoke.
has anyone on Slashdot EVER written a friendly letter (attempted seduction counts) and sent it by snail mail
Heh, I'm reminded of Dostoyevsky's (I think it was Dostoyevsky) comment:
"I've written poetry
In pusuit of seduction
That is,
For the sake of a worthy cause."
Probably more due to the fact that Java apps tend to be big -- not because Java is "bloated", but because Java's OO-nature makes it easier to write large apps. I've written little command-line utilities that don't take appreciably longer to start than others written in C. Large apps like ArgoUML may take longer to start, but once you're in them you're there for a couple of hours, so an extra ten seconds or so on the front end really isn't going to make any difference.
With enough pressure yes, water will solidify.
Awesome! At my next party, I'm going to have forged ice cubes! And I'll put 'em in the grill and fry steaks with them!
One must wonder why water cores don't exist in real life...
Oh but they do!
I'd have to go with the VB crowd. First off, any reasonably recent (since WinME) version of Windows will already have the VB runtime installed. Plus, VB (at least as of version 5, which is the last version I used) has a built-in installer builder/packager. Once the app is done, you just identify the files it uses (in his case, probably one .frx and maybe a third-party control to read the serial port), then push a button and it spits out a ready-to-distribute installer. It's no InstallSheild, but it's perfect for this project.
Nothing against Tcl (actually, I hate it, but this would be a good application for it), but apps built against Tk don't look quite like Windows apps. Not sure if that would be a factor, but the principle of least astonishment would seem to apply here.
Not like they didn't come close... (search for "pogo oscillation")