... large number of CS majors apparently believe that everything can be implemented in a virtual machine and that both memory and [CPU] cycles are infinite.
Not an embedded system, per se (more like a "headless system"), but I was involved in a project where certain aspects of the design (aspects that I had no input into) more or less assumed infinite memory and CPU.
The design itself on paper was beautiful: symmetric, orthogonal, intuitive, complete.
But when implemented, the design SUCKED because it ran like molasses on a cold day. Everything that could be done to increase its performance was tried, and in the end its performance still sucked. The whole thing had to be re-designed, and rebuilt from scratch. The original designers (C.S. degrees, of course) howled about "engineering hacks" the whole time.
The final design was uglier on paper, but it ran several orders of magnitude faster than the original.
TFA says
The software giant also said that it has an integration plan to include employees of both companies and intends to offer incentives to retain Yahoo employees.
I can see it now. The first step of the "integration plan" is to replace Yahoo's server stack with MS products.
Hear, hear. Once upon a time I designed a packet-ized format for data telemetry and storage. The design was straightforward, but it included a variable-sized record-header (but always a factor of 8) on top of variable-sized record payloads. I thought it was a good idea at the time, but it turned out to be problematic for S/W implementation, especially for inexperienced devs. I could have saved ourselves a lot of time and pain if I had made the record headers fixed-length. Mea culpa.
Makes one appreciate just how complex handling TCP/IP can be. I can't imagine how it could easily be ported to firmware. It obviously can be done, but it's no easy task.
... the code that I've written that actually works (eg does something useful) and that has actually shipped.
In the course of my career, it turns out that more often than not, the code that's simultaneously been the most useful and that has actually shipped has been my cowboy code: quick-n-dirty programs; bash-scripts, perl-scripts, one-offs, and the like.
I've also produced a lot of code under "best practices", and I've found that while this is useful (and it's generally the right way to do things), this code has a tendency to never ship. It (along with a lot of other useful code written by a lot of smart programmers) tends to gets stuck somewhere in the "process" and languishes. Sometimes, it eventually oozes out of the "process" and ships. More often, it just dies a lonely death somewhere in the repository.
I don't care about code that isn't useful or that never gets used. It could be beautiful, well designed, easy-to-maintain code. But if it never ships and never gets used, it's absolutely worthless.
So, yeah. I'm most proud of my cowboy code that has been shipped and that gets used. It may not be fun to read or maintain, but by God, it's useful and it's getting used. That's the primary goal of this industry.
I'd rather have a machine with slower CPU but with wide, fast busses and smart, fast I/O subsystems, then a machine with a faster CPU but with crappy I/O. Maybe I'm just wierd that way.
From http://en.wikipedia.org/wiki/Leap_second
For example, as things presently stand, it is not possible to correctly compute the elapsed interval between two stated instants of UTC without consulting manually updated and maintained tables of when leap seconds have occurred. Moreover, it is not possible even in theory to compute such time intervals for instants more than about six months in the future. This is not a matter of computer programmers being "lazy"; rather, the uncertainty of leap seconds introduces to those applications needing accurate notions of elapsed time intervals either fundamentally new (and often untenable) operational burdens for computer systems (the need to be online and do lookups) or unsurmountable theoretical concerns (the inability in a UTC-based computer to accurately schedule any event more than six months in the future).
A counter to this argument is that computers need not use UTC. They could use either TAI or GPS time and convert to UTC or local civil time as necessary for output. GPS time is an especially convenient choice as inexpensive GPS timing receivers are readily available and the satellite broadcasts include the necessary information to convert GPS time to UTC.
All of our software uses GPS time as a time reference. All of our data is timestamped with GPS time. When a conversion to/from UTC happens, the software uses a hard-coded leap-second table to apply the correct UTC-GPS offset. When a new leap second is announced, someone has to remember to go update the table and rebuild the software. Not the best scheme in the world, but the software is close to 20 years old.
There's no other way to compute the elapsed time between two events unless you use a continuous time scale.
What's your repository model? Stable trunk? Unstable trunk? Does that patch go into a current release branch or a new release branch, and/or is it also supposed to go into the patch branch and/or is it supposed to go into the baseline branch? Who's the gate keeper for the baseline branches? (please don't say that any developer can check in here!) Maybe that fix is also supposed to go into the future baseline branch. Can you point to a place in your code repository where the latest stable branch is? The last released baseline? The baseline before that? OK, if not you, then who can provide that information? How do you roll back a patch if necessary? You just go back to the last baseline, right? Do you have enough resources to do full-up testing for all these code branches and scenarios? What are the policies and decision making process for where patches land and how they're tested? What's your branching policy for getting new features added to the codebase?
When you're talking millions of LOC, these issues matter.
Under OSX? Sure there is. Say you want to merge the contents of two folders "a" and "b" into a new folder "c". It's pretty simple really. Start up a shell and run the following:
mkdir c && ( cd a/. && tar cf - . ) | ( cd c/. && tar xf - ) && ( cd b/. && tar cf - . ) | ( cd c/. && tar xf - )
Java's main point to that enables applications to be easily portable across mutliple OS platforms.
Apple cares primarily about portability across Apple platforms. Apple wants your applications to be portable across Apple products. They have ways to accomplish this that don't involve Java. Look at the iPhone SDK. Java's nowhere to be found.
Apple doesn't really care whether or not your applications are portable to non-Apple platforms.
So, Java will always be a 2nd class citizen in the Apple world.
In case anyone hasn't been paying attention, Apple's primary concern is portability across Apple products, not portability across myriad OS platforms. Apple could care less whether your application runs on a non-Apple product.
It won't preclude the existence of Java on OSX, but it certianly points to the fact that Java on OSX will be treated as a 2nd class citizen by Apple.
As far as portability is concerned: the combination of LLVM, Cocoa, Xcode, etc., will provide all the portability that Apple cares about. Which is to say, portability between Apple products.
Given that Apple products are, in essence, easy-to-use multimedia centers (as opposed to computers), -- and that trend will accelerate to be sure -- I think it's a smart move. They'll control their own platform.
The future of Java on OSX is explained in the LLVM section here:
Apple has grand plans for LLVM. How grand? How about swapping out the guts of the gcc compiler Mac OS X uses now and replacing them with the LLVM equivalents? That project is well underway. Not ambitious enough? How about ditching gcc entirely, replacing it with a completely new LLVM-based (but gcc-compatible) compiler system? That project is called Clang, and it's already yielded some impressive performance results. In particular, its ability to do fast incremental compilation and provide a much richer collection of metadata is a huge boon to GUI IDEs like Xcode.
I know this LLVM subsection is quite a digression, but even if it's only used in a limited capacity in Leopard, LLVM is quite important to the future of Mac OS X. Indeed, it could also be important to the present of the iPhone and other OS X platforms.
Which says that there is no future for Java under OSX.
Slashdot Mirror
... large number of CS majors apparently believe that everything can be implemented in a virtual machine and that both memory and [CPU] cycles are infinite.Not an embedded system, per se (more like a "headless system"), but I was involved in a project where certain aspects of the design (aspects that I had no input into) more or less assumed infinite memory and CPU.
The design itself on paper was beautiful: symmetric, orthogonal, intuitive, complete.
But when implemented, the design SUCKED because it ran like molasses on a cold day. Everything that could be done to increase its performance was tried, and in the end its performance still sucked. The whole thing had to be re-designed, and rebuilt from scratch. The original designers (C.S. degrees, of course) howled about "engineering hacks" the whole time.
The final design was uglier on paper, but it ran several orders of magnitude faster than the original.
TFA says The software giant also said that it has an integration plan to include employees of both companies and intends to offer incentives to retain Yahoo employees.
I can see it now. The first step of the "integration plan" is to replace Yahoo's server stack with MS products.
That's a joke, right?
I think Google's already taken care of all the experimental evaluations you'd need.
Transportelator
Photon torpedolator
Holodeckelator
Tractelator Beam
Tricordelator
Warpelator Drive
M3? Please. Four wheels is two too many.
If you're looking for a REAL BMW, look no further.
It wasn't the variable-sized headers that caused the bugs; they were fine with that. It was the variable-sized record headers that did the trick.
But your point is taken. But, I'm not ever expecting this data format to be subsumed into firmware.
Hear, hear. Once upon a time I designed a packet-ized format for data telemetry and storage. The design was straightforward, but it included a variable-sized record-header (but always a factor of 8) on top of variable-sized record payloads. I thought it was a good idea at the time, but it turned out to be problematic for S/W implementation, especially for inexperienced devs. I could have saved ourselves a lot of time and pain if I had made the record headers fixed-length. Mea culpa.
Makes one appreciate just how complex handling TCP/IP can be. I can't imagine how it could easily be ported to firmware. It obviously can be done, but it's no easy task.
I'm not a datacenter kind of guy, so help me out. If you've got 10 G Ethernet, then why would you want to run FC rather than iSCSI?
Can someone elaborate?
... But are 'friends' electric?
Only mine's broke down
And now I've no one to love
If you don't get the reference, then you're just too young!
... the code that I've written that actually works (eg does something useful) and that has actually shipped.
In the course of my career, it turns out that more often than not, the code that's simultaneously been the most useful and that has actually shipped has been my cowboy code: quick-n-dirty programs; bash-scripts, perl-scripts, one-offs, and the like.
I've also produced a lot of code under "best practices", and I've found that while this is useful (and it's generally the right way to do things), this code has a tendency to never ship. It (along with a lot of other useful code written by a lot of smart programmers) tends to gets stuck somewhere in the "process" and languishes. Sometimes, it eventually oozes out of the "process" and ships. More often, it just dies a lonely death somewhere in the repository.
I don't care about code that isn't useful or that never gets used. It could be beautiful, well designed, easy-to-maintain code. But if it never ships and never gets used, it's absolutely worthless.
So, yeah. I'm most proud of my cowboy code that has been shipped and that gets used. It may not be fun to read or maintain, but by God, it's useful and it's getting used. That's the primary goal of this industry.
If this is true, then all GPLed software is "proprietary by definition".
Wasn't that back in the late-70s/early-80s?
Pure coincidence that I happened to be listening to "The Pleasure Principle" when I checked to see what was happening on Slashdot.
Rock on Polymoogs!
Sadly, I have to agree. Or, I have to sadly agree. Or something.
... more general and well maintained VMI'd rather have a machine with slower CPU but with wide, fast busses and smart, fast I/O subsystems, then a machine with a faster CPU but with crappy I/O. Maybe I'm just wierd that way.
All of our software uses GPS time as a time reference. All of our data is timestamped with GPS time. When a conversion to/from UTC happens, the software uses a hard-coded leap-second table to apply the correct UTC-GPS offset. When a new leap second is announced, someone has to remember to go update the table and rebuild the software. Not the best scheme in the world, but the software is close to 20 years old.
There's no other way to compute the elapsed time between two events unless you use a continuous time scale.
Published leap offset? What if your system happens to not be on the Internet?
Fair enough.
What's your repository model? Stable trunk? Unstable trunk? Does that patch go into a current release branch or a new release branch, and/or is it also supposed to go into the patch branch and/or is it supposed to go into the baseline branch? Who's the gate keeper for the baseline branches? (please don't say that any developer can check in here!) Maybe that fix is also supposed to go into the future baseline branch. Can you point to a place in your code repository where the latest stable branch is? The last released baseline? The baseline before that? OK, if not you, then who can provide that information? How do you roll back a patch if necessary? You just go back to the last baseline, right? Do you have enough resources to do full-up testing for all these code branches and scenarios? What are the policies and decision making process for where patches land and how they're tested? What's your branching policy for getting new features added to the codebase?
When you're talking millions of LOC, these issues matter.
... Google announces that MULTICS code will be incorporated into Android.
I know how you feel. I also didn't get an offer.
Java's main point to that enables applications to be easily portable across mutliple OS platforms.
Apple cares primarily about portability across Apple platforms. Apple wants your applications to be portable across Apple products. They have ways to accomplish this that don't involve Java. Look at the iPhone SDK. Java's nowhere to be found.
Apple doesn't really care whether or not your applications are portable to non-Apple platforms.
So, Java will always be a 2nd class citizen in the Apple world.
I thought everyone would have gotten this by now.
Sorry; let me clarify.
It won't preclude the existence of Java on OSX, but it certianly points to the fact that Java on OSX will be treated as a 2nd class citizen by Apple.
As far as portability is concerned: the combination of LLVM, Cocoa, Xcode, etc., will provide all the portability that Apple cares about. Which is to say, portability between Apple products.
Given that Apple products are, in essence, easy-to-use multimedia centers (as opposed to computers), -- and that trend will accelerate to be sure -- I think it's a smart move. They'll control their own platform.
Which says that there is no future for Java under OSX.