I know of a magazine that quoted endlessly (years ago) that OS/2 was a dead-end operating system because it only had 2,000 native applications. Later, the same magazine published a story about how Windows NT was gaining good momentum, as evidenced by its 1,200 native applications.
While this may seem insightful when he quotes this "magazine", it appears that it was dead-on, many "years ago." Despite the stipulated fact that OS/2 had many more applications, it was clear then that NT had the future.
All I know is that in my shop Linux has become a good thing. It wasn't until recently. You no longer fear FUDish looks if you suggest that something could be done better, if not at least cheaper, on Linux. Linux compatibility has become a key criteria for hardware acquisition. This is from a site that had never had any form of non-Microsoft. This change is in part due to recent turn-over in IT staff. Indirectly, it has also happened because people in the IT sector are talking about Linux frequently in terms of real implementations, especially on resumes. Executives are noticing.
For us, Linux adoption is motivated by three things in no particular order; manageability, reliability and cost. Manageability means not having to cope with immature, half baked, complex GUI only service software for email, http, filesystems, backups, periodic jobs, etc. To us, reliability means not having to put up with the random, mysterious nonsense (crashes, hangs, corruption, security holes, etc.) that we witness daily with Microsoft products that aren't nursed constantly with patches and rebuilds. Cost is a given, provided the necessary talent exists. Such talent is now criteria for hiring.
It is also clear to me that Linux is claiming enormous mind share. Sourceforge et al wouldn't exist otherwise. I think that mind share is the key because it means the market has found something credible. I mean found in the sense of judged, as opposed to discovered. Linux has moved beyond geeks, hobbyists and isolated vertical markets. I think the credit belongs, in part, to those same geeks and hobbyists.
I am no zealot. Linux works well for a subset of the things I'm expected to do. It is not a universal solution for all problems. Fortunately, there does appear to be room in the future IT market for multiple platforms. As long as that's the case, Linux has time to progress.
gzip was designed with such considerations in mind. Throughput of the algorithm took precedence over compression level. Good to see their farsightedness paying off.
I think that if one were planning to dedicate hardware to the task of compression, one would decide that space should take precedence over speed. Performance is the reason that hardware gets dedicated to a task. Why design something to be efficient with your CPU, and then solve the efficiency problem with dedicated CPUs?
And the algorithm is pretty simple so that it can be implemented in hardware directly.
Are there any compression algorithms so complex that they can't be implemented in hardware? I don't know the implementation details of this particular bit of dedicated hardware, but I seriously doubt that the gzip algorithm was actually implemented directly in the gates and capacitors of a silicon chip. More likely it is either re-configurable logic, or a general purpose CPU (ARM et al) with some firmware.
Due to the large amount of ore that must be refined to build SUV for Americans, the magnetosphere of Earth has deformed and is now causing the Solar Corona to expand. This expansion is causing increased radiation, and hence, higher ambient temperatures on Earth.
Why is that obvious? I, for one, don't see it at all. XFree86 sends stuff to your video card and your monitor, the audio drivers send stuff to your sound card and your speakers.
Because audio output must often be synchronized with video. In the last couple days I have probably watched a dozen bits of video about our most recent adventure in Iraq. These video clips have an audio component, and that audio must be synchronized with the pictures. Games have the same requirement. Video conferencing has the same requirement.
All of this works now with X Windows locally. What if I want it to run this remotely? It probably requires a couple Mbps to stream the frames. This is no problem at all for my 100Mbps network. I can pull up Real (or whatever) and run it remotely and it works fine. It's also dead silent. No path for the noise.
There are ongoing attempts to solve this problem. There are several competing, alternative, redundant systems that will stream audio between hosts. Because there are many to choose from, each with a unique API and unique limitations, and various levels of maturity, none of them are being used widely enough to become a de facto solution. Audio must be integrated with video to provide a path for all of the media. X Windows provides only graphics.
The exact same point applies to printing. There is no widespread method of taking what is rendered in an X Windows display and putting it on paper. There are fledgling attempts to do this. XPrint comes to mind. There are various redundant, competing facilities provided by various GUI abstraction layers (GNOME, Qt, etc.) that do this. There is no native, standard way to do this. Thus, none of them ever obtain enough widespread attention to provide a de facto solution. They all suck in unique ways.
With the modularization of hardware drivers in XFree86 4.x, this is much less of an issue. You can drop in your own hardware driver into a stock XFree86 (in fact, a binary hardware driver written for linux will often work on FreeBSD, it's that good). What more are you looking for?
Indeed, this is the case. Now I want to see this taken further. The low level driver modules could be better maintained separately from the general XFree development process. These modules are also useful on their own because they generalize hardware capabilities behind a uniform API.
Wake up. TrueType is supported
Obviously. My point is that TrueType is all that needs supporting. The byzantine, crufty mess that is X Windows fonts helps nothing. Microsoft manages to be successful with almost nothing but TrueType. I don't pay the font zealots much heed. They can pay to cost of whatever pedantic collection of font systems they feel they must have, just like they do in Windows. "The rest of us" don't care to hear it.
XFree86 does ship with a WM -- twm. Like it?
Why do you believe that "standard" implies poor? I believe that having a standard window manager would result in a high quality, trusted, implementation. Twm is pretty poor. In my experience, so are most of the alternatives. Perhaps, with fewer alternatives to dilute the development focus, we might end up with something better?
Again, if you like Qt, use Qt. If you like Gnome, use Gnome...It's all about choice
Really? Perhaps the truth is that all of these alternatives exist primarily because the native X Windows APIs; XLib, Xt and higher level tools such as Motif, are clearly shit that badly need replacing. The basic MS Windows GDI API is reasonably easy to comprehend and use directly. The MFC API is a vast improvement on this. If the native API of your GUI is a pleasant and reasonable collection of interfaces, most developers feel no compelling urge to build multiple, alternative, competing layers on top of it to hide the ugly.
Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
Before anyone gets confused, lets be clear and point out that this is the IT equivalent of a theory. Basically, we are told the client should be just smart enough to render controls and pass input events back to the server. This is theory because there are no implementations of this in widespread use.
The quote suggests that Bonobo or Kparts would implement the client side controls. These controls are then driven from the server via RPC or some other mechanism.
Some argue that web browsers could do this. Perhaps. The inherent statelessness of web clients preclude large classes of GUI applications and makes others very difficult. Can you imagine a browser based implementation of, say, Paint? (activex/java doesn't count.) Lots of applications have grids with re-sizable columns, yet common browsers have never provided this without add-ons or substantial hackery.
There have been and are real attempts to make this theory work, however. An excellent example is XWT. Check it out. There are others, but they're even more obscure and even less likely to ever actually matter.
Why is this? Lots of people have this notion of half-smart clients that provide 99% of "direct" GUI fidelity by rendering controls on behalf of some server somewhere. There is nothing new under the sun. Yet it doesn't happen.
Here is my contribution: Z Windows (I think there is a Y Windows out there,) an evolution of X Windows:
- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.
- It's obvious audio must be integral. Integrate it.
- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.
- Create a standard window manager. All others accept the consequences of being weird. Life is short.
- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.
Now you have a clean, straightforward system that has a good API, sound, good fonts and drivers that are easy(er) to implement. Applications arrive shortly thereafter because your using a worthwhile API.
What about network transparency? Well, in case you haven't noticed, the most widespread use of network transparent GUI is Citrix. It works well, thank you very much. It would work even better if it had been incorporated from the start by the underlying GUI. Citrix is nothing more than a highly optimized screen scraper, much like VNC. It turns out, despite the best thinking on the matter, that this is sufficient for 99.9999% of all remote GUI purposes, and the remaining 0.0001% (high performance graphics work) you want local anyhow.
Congratulations. You now have a worthy GUI system for the next 15 years. Now wake up.
can anyone tell me why Saddam sets fire to the oil fields?
It screws up visibility pretty badly. This matters a lot for aircraft navigation. Poor visibility also hinders laser guided bombing.
Not that it matters much now. Apparently most of the prediction ordinance uses GPS and inertial guidance now, which obviates lasers. However, I'm sure this isn't yet universal.
XDoclet is a code generator. It uses metadata in JavaDoc tags to generate source files that make a complete EJB. This is merely one function of an integrated environment. XDoclet does not provide integrated version control, integrated UML design, server side debugging or any other of a large number of features you get with a typical J2EE development tool such as JDeveloper 9i.
I'm not knocking XDoclet or JBoss or anything else. I'm only pointing out that there are obvious advantages to the commercial platforms. When a project grows beyond a handful of geeks you need "high-touch" tools.
I know J2EE developers that could just barely manage to install J2SE+J2EE properly on their local machine on a good day. You can not expect these people to adopt XDoclet/Ant/CVS/ArgoUML/etc and make it all function productively. You can expect them to write perfectly good business applications from within an integrated environment.
Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable
Sun probably does know. If you were Phipps, would it be better to simply proclaim that JBoss is not compliant and create an Open Source "martyr" or merely suggest it isn't and let the JBoss Group prove you wrong?
Personally I doubt it is actually compliant. The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous. The big vendors spend a lot of time massaging their products to comply with the spec with the benefit of the licensed test suit at their disposal. JBoss hasn't had this luxury. They'll need to go through this process before all the light turn green. Don't be surprised if it takes the JBoss Group a year to get there.
I don't blame Sun for withholding certification from JBoss. They have managed to get powerful vendors to sign on to the J2EE platform based on the promise that there is a payoff in terms of licenses. Now that these big vendors have established a credible market for the platform, Sun can let JBoss play and provide a low cost point of entry. Had a "free", certified compliant implementation existed early the big vendors may have thought better of it. Sun now wants JBoss compliant because it makes the platform stronger to have a solid low-cost implementation.
JBoss is not threat to the big J2EE vendors. Implementing a single server side class in J2EE requires writing at least three separate bits of Java code for the home, remote and bean interfaces/classes. There may also be local variants of these to overcome marshalling overhead. XML metadata must also be maintained. This is for a single EJB. If you have many EJBs, you have a very large number of source files and bits of metadata that must be kept in sync. The big commercial vendors sell tools that make this easy. You can do it with vi, but you don't want to. If JBoss is really compliant and really as good as its hype, the vendors will just incorporate it into their own products, just like they did Apache. Their "value add" still remains, because JBoss does little or nothing to relieve the sheer development burden of distributed J2EE development (aside from good dynamic deployment.)
J2EE is now technically credible and supported by real vendors with real products. Now Sun wants to make it cost effective by allowing JBoss to compete after getting its certification ducks in a row. Wise move.
Re:I'm for the war... but..
on
Strike on Iraq
·
· Score: 1
Here is an interesting link. Short version: Iraqi agents use plastic shredders to execute people. You know, shredders to recycle plastic objects. Big metal drums that grind stuff up.
The 90's were fun. The 90's were made of stuff like this. You know, PDAs and stuff. Don't pick on him. Goofy crap like this can pay for Real Estate.
At the very least Cliff is a barometer. If people still has the leisure to actually care about this we're doing fairly well. Look man, we're about to topple a regime. We have "Ambient Orbs" to fill the commercial breaks.
Anyhow, when I hit the term "Ambient Orb", I immediately recalled "Happy Fun Ball", from SNL. Does anyone else remember hyperventilating over that bit when it was new? Difference is that was parody. "Ambient Orb" you pay for. I bet the guy who wrote the "Happy Fun Ball" skit is kicking himself now.
"If I were a Country trying to defend myself against any military force today that depends on technology"
It ain't that easy to monkey with someone else's satellites. If you radiate, you die. This, of course, precludes jamming. If you're third world, you have no means to put stuff in orbit, or if you do, no means to aim it. GPS satellites and geosync transponders are as far out of Iraq's reach as the Saturn. Forgetaboutit. Even if you're first world, your enemy can move, hide, defend and replace anything you shoot at.
lot of innocent civilians...have been, are and will be killed by Saddam whether we french around or not.
A man tried to escape to Northern Iraq a few days ago. Bathe Party folks captured him. They tied him to a pole, cut out his tounge and let him bleed to death in public. Guess they were too busy to find an acid vat.
Limiting the physical memory to 40 bits reduces the cost of building other system components, such as chipsets and motherboards, dramatically. Further, 1TB of RAM is sufficient for the current market. That is 1000 1GB parts, to give it some perspective.
As customers begin to approach 1TB requirements, AMD only has to implement more lines. No need for any segmentation hacks. The ISA needs no modification. This is a pragmatic and wise design decision.
64 bits of address space is still very useful without having actual RAM to back it up. It means you can map large quantities of storage into RAM directly. For example; if you have 10TB of disk, you can map all of it into a single virtual address space and address it with simple offsets. Obviously this is useful for large databases.
"That's something you won't get moving to a Linux/AMD solution."
Major vendors (IBM, HP, etc) offer this level of support (and better) for there Linux products right now. Sun does too. When these vendors sell x86-64 CPUs, they will offer the same level of support on day 1. This is understood.
Unlike the Itanium, AMD's 64-bit procs are not emulating 32bit compatibility...
All AMD CPUs are "emulating" the x86 ISA. Athlons decompose x86 instructions and execute them on an essentially RISC core, no? AMD CPUs happen to do it very well, routinely matching higher frequency Intel parts.
Can they provide more bus lines in the future without ISA modifications? If so, then this is a smart design decision. Using only 40 bit addresses reduces the cost of the complete system while providing enough address space.
Oh no, a ten round magazine is far more terrifying than that. With armor piercing rounds and careful alignment of your shots it will kill at least 20 people! Of course, any competent shooter will have one round in the chamber in addition to the magazine, so there's another two dead innocents. Naturally one should consider using tiny gas dispensers in the rounds for an area effect. Certainly that would be good for 100 or more! At some point the NRA will finally succeed in producing tiny fission warheads. At that point 10 rounds should be good for wasting several hundred!
...but I suppose as this gets complicated the performance of the SQL queries required to answer questions like (in pseudo-code) SELECT Address WHERE Street Contains "Main Street" becomes difficult...
It shouldn't have to. Some RDBMS systems allow you to optimize locality of rows from multiple tables based on some key. Oracle calls this a "table cluster". Rows from multiple tables are stored together on disk when their keys match across tables. They behave like normal tables in most other respects. Query a particular row from any cluster member and the engine will pick up the related rows automatically in one IO operation.
This is a very efficient way to create table-like structures at runtime. You create an "attribute" table for each significant data-type and cluster all the tables together, then you just create views to make the separate attribute rows appear as a single row in a query.
I can't imagine why it wouldn't apply to XML. I'll bet it's done this way in real XML database implementations.
These old news stories are hard to recover because even Google doesn't preserve everything forever...
However, here's a URL to a page that mentions a case in Italy: http://www.angelfire.com/on2/oddnews/issue 9.html
Here is an article with a bunch of cases. In the Hamburg case, the man died and remained undiscovered for half a decade. http://melvindurai.com/dead.htm
"I think most of the credit should go to the 386 implementors"
Intel no more invented TLBs than Linus invented fork(). The x86 ISA and the Unix design are both the result of countless prior efforts. They evolved symbiotically over many generations, using many hardware platforms. Attempting to ascribe any particular percentage of credit to one or the other is naive. It took decades of effort to arrive at the contemporary model. The truth is that IBM implemented most of the significant features of multitasking virtual memory systems, both hardware and software, before Linus was born.
There's a german architect named Albert Speer who has done some work for the german government on this idea, though I understand it to be quite controversial.
Every now and they someone discoverers a pensioner somewhere in the fatherland that's been dead in their home for a couple years. It seems that one can arrange things so that the government payouts are deposited in an account, and all your recurring debts are automatically paid from there. If you don't have friends or family that care enough to visit, you're free to die and go unnoticed indefinitely.
Think of it... somewhere in Berlin or Hamburg there are skeletons propped up in chairs with bowls of chips in theirs laps, faithfully watching to tube. Now all we need is apartments that last hundreds of years. At some point a certain percentage of units will have 200 year old occupants that never come out.
BTW, this isn't urban legend. It's been widely reported on several occasions.
Slashdot Mirror
I know of a magazine that quoted endlessly (years ago) that OS/2 was a dead-end operating system because it only had 2,000 native applications. Later, the same magazine published a story about how Windows NT was gaining good momentum, as evidenced by its 1,200 native applications.
While this may seem insightful when he quotes this "magazine", it appears that it was dead-on, many "years ago." Despite the stipulated fact that OS/2 had many more applications, it was clear then that NT had the future.
All I know is that in my shop Linux has become a good thing. It wasn't until recently. You no longer fear FUDish looks if you suggest that something could be done better, if not at least cheaper, on Linux. Linux compatibility has become a key criteria for hardware acquisition. This is from a site that had never had any form of non-Microsoft. This change is in part due to recent turn-over in IT staff. Indirectly, it has also happened because people in the IT sector are talking about Linux frequently in terms of real implementations, especially on resumes. Executives are noticing.
For us, Linux adoption is motivated by three things in no particular order; manageability, reliability and cost. Manageability means not having to cope with immature, half baked, complex GUI only service software for email, http, filesystems, backups, periodic jobs, etc. To us, reliability means not having to put up with the random, mysterious nonsense (crashes, hangs, corruption, security holes, etc.) that we witness daily with Microsoft products that aren't nursed constantly with patches and rebuilds. Cost is a given, provided the necessary talent exists. Such talent is now criteria for hiring.
It is also clear to me that Linux is claiming enormous mind share. Sourceforge et al wouldn't exist otherwise. I think that mind share is the key because it means the market has found something credible. I mean found in the sense of judged, as opposed to discovered. Linux has moved beyond geeks, hobbyists and isolated vertical markets. I think the credit belongs, in part, to those same geeks and hobbyists.
I am no zealot. Linux works well for a subset of the things I'm expected to do. It is not a universal solution for all problems. Fortunately, there does appear to be room in the future IT market for multiple platforms. As long as that's the case, Linux has time to progress.
gzip was designed with such considerations in mind. Throughput of the algorithm took precedence over compression level. Good to see their farsightedness paying off.
I think that if one were planning to dedicate hardware to the task of compression, one would decide that space should take precedence over speed. Performance is the reason that hardware gets dedicated to a task. Why design something to be efficient with your CPU, and then solve the efficiency problem with dedicated CPUs?
And the algorithm is pretty simple so that it can be implemented in hardware directly.
Are there any compression algorithms so complex that they can't be implemented in hardware? I don't know the implementation details of this particular bit of dedicated hardware, but I seriously doubt that the gzip algorithm was actually implemented directly in the gates and capacitors of a silicon chip. More likely it is either re-configurable logic, or a general purpose CPU (ARM et al) with some firmware.
Due to the large amount of ore that must be refined to build SUV for Americans, the magnetosphere of Earth has deformed and is now causing the Solar Corona to expand. This expansion is causing increased radiation, and hence, higher ambient temperatures on Earth.
Why is that obvious? I, for one, don't see it at all. XFree86 sends stuff to your video card and your monitor, the audio drivers send stuff to your sound card and your speakers.
Because audio output must often be synchronized with video. In the last couple days I have probably watched a dozen bits of video about our most recent adventure in Iraq. These video clips have an audio component, and that audio must be synchronized with the pictures. Games have the same requirement. Video conferencing has the same requirement.
All of this works now with X Windows locally. What if I want it to run this remotely? It probably requires a couple Mbps to stream the frames. This is no problem at all for my 100Mbps network. I can pull up Real (or whatever) and run it remotely and it works fine. It's also dead silent. No path for the noise.
There are ongoing attempts to solve this problem. There are several competing, alternative, redundant systems that will stream audio between hosts. Because there are many to choose from, each with a unique API and unique limitations, and various levels of maturity, none of them are being used widely enough to become a de facto solution. Audio must be integrated with video to provide a path for all of the media. X Windows provides only graphics.
The exact same point applies to printing. There is no widespread method of taking what is rendered in an X Windows display and putting it on paper. There are fledgling attempts to do this. XPrint comes to mind. There are various redundant, competing facilities provided by various GUI abstraction layers (GNOME, Qt, etc.) that do this. There is no native, standard way to do this. Thus, none of them ever obtain enough widespread attention to provide a de facto solution. They all suck in unique ways.
With the modularization of hardware drivers in XFree86 4.x, this is much less of an issue. You can drop in your own hardware driver into a stock XFree86 (in fact, a binary hardware driver written for linux will often work on FreeBSD, it's that good). What more are you looking for?
Indeed, this is the case. Now I want to see this taken further. The low level driver modules could be better maintained separately from the general XFree development process. These modules are also useful on their own because they generalize hardware capabilities behind a uniform API.
Wake up. TrueType is supported
Obviously. My point is that TrueType is all that needs supporting. The byzantine, crufty mess that is X Windows fonts helps nothing. Microsoft manages to be successful with almost nothing but TrueType. I don't pay the font zealots much heed. They can pay to cost of whatever pedantic collection of font systems they feel they must have, just like they do in Windows. "The rest of us" don't care to hear it.
XFree86 does ship with a WM -- twm. Like it?
Why do you believe that "standard" implies poor? I believe that having a standard window manager would result in a high quality, trusted, implementation. Twm is pretty poor. In my experience, so are most of the alternatives. Perhaps, with fewer alternatives to dilute the development focus, we might end up with something better?
Again, if you like Qt, use Qt. If you like Gnome, use Gnome...It's all about choice
Really? Perhaps the truth is that all of these alternatives exist primarily because the native X Windows APIs; XLib, Xt and higher level tools such as Motif, are clearly shit that badly need replacing. The basic MS Windows GDI API is reasonably easy to comprehend and use directly. The MFC API is a vast improvement on this. If the native API of your GUI is a pleasant and reasonable collection of interfaces, most developers feel no compelling urge to build multiple, alternative, competing layers on top of it to hide the ugly.
Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
Before anyone gets confused, lets be clear and point out that this is the IT equivalent of a theory. Basically, we are told the client should be just smart enough to render controls and pass input events back to the server. This is theory because there are no implementations of this in widespread use.
The quote suggests that Bonobo or Kparts would implement the client side controls. These controls are then driven from the server via RPC or some other mechanism.
Some argue that web browsers could do this. Perhaps. The inherent statelessness of web clients preclude large classes of GUI applications and makes others very difficult. Can you imagine a browser based implementation of, say, Paint? (activex/java doesn't count.) Lots of applications have grids with re-sizable columns, yet common browsers have never provided this without add-ons or substantial hackery.
There have been and are real attempts to make this theory work, however. An excellent example is XWT. Check it out. There are others, but they're even more obscure and even less likely to ever actually matter.
Why is this? Lots of people have this notion of half-smart clients that provide 99% of "direct" GUI fidelity by rendering controls on behalf of some server somewhere. There is nothing new under the sun. Yet it doesn't happen.
Here is my contribution: Z Windows (I think there is a Y Windows out there,) an evolution of X Windows:
- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.
- It's obvious audio must be integral. Integrate it.
- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.
- Create a standard window manager. All others accept the consequences of being weird. Life is short.
- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.
Now you have a clean, straightforward system that has a good API, sound, good fonts and drivers that are easy(er) to implement. Applications arrive shortly thereafter because your using a worthwhile API.
What about network transparency? Well, in case you haven't noticed, the most widespread use of network transparent GUI is Citrix. It works well, thank you very much. It would work even better if it had been incorporated from the start by the underlying GUI. Citrix is nothing more than a highly optimized screen scraper, much like VNC. It turns out, despite the best thinking on the matter, that this is sufficient for 99.9999% of all remote GUI purposes, and the remaining 0.0001% (high performance graphics work) you want local anyhow.
Congratulations. You now have a worthy GUI system for the next 15 years. Now wake up.
can anyone tell me why Saddam sets fire to the oil fields?
It screws up visibility pretty badly. This matters a lot for aircraft navigation. Poor visibility also hinders laser guided bombing.
Not that it matters much now. Apparently most of the prediction ordinance uses GPS and inertial guidance now, which obviates lasers. However, I'm sure this isn't yet universal.
XDoclet is a code generator. It uses metadata in JavaDoc tags to generate source files that make a complete EJB. This is merely one function of an integrated environment. XDoclet does not provide integrated version control, integrated UML design, server side debugging or any other of a large number of features you get with a typical J2EE development tool such as JDeveloper 9i.
I'm not knocking XDoclet or JBoss or anything else. I'm only pointing out that there are obvious advantages to the commercial platforms. When a project grows beyond a handful of geeks you need "high-touch" tools.
I know J2EE developers that could just barely manage to install J2SE+J2EE properly on their local machine on a good day. You can not expect these people to adopt XDoclet/Ant/CVS/ArgoUML/etc and make it all function productively. You can expect them to write perfectly good business applications from within an integrated environment.
Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable
Sun probably does know. If you were Phipps, would it be better to simply proclaim that JBoss is not compliant and create an Open Source "martyr" or merely suggest it isn't and let the JBoss Group prove you wrong?
Personally I doubt it is actually compliant. The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous. The big vendors spend a lot of time massaging their products to comply with the spec with the benefit of the licensed test suit at their disposal. JBoss hasn't had this luxury. They'll need to go through this process before all the light turn green. Don't be surprised if it takes the JBoss Group a year to get there.
I don't blame Sun for withholding certification from JBoss. They have managed to get powerful vendors to sign on to the J2EE platform based on the promise that there is a payoff in terms of licenses. Now that these big vendors have established a credible market for the platform, Sun can let JBoss play and provide a low cost point of entry. Had a "free", certified compliant implementation existed early the big vendors may have thought better of it. Sun now wants JBoss compliant because it makes the platform stronger to have a solid low-cost implementation.
JBoss is not threat to the big J2EE vendors. Implementing a single server side class in J2EE requires writing at least three separate bits of Java code for the home, remote and bean interfaces/classes. There may also be local variants of these to overcome marshalling overhead. XML metadata must also be maintained. This is for a single EJB. If you have many EJBs, you have a very large number of source files and bits of metadata that must be kept in sync. The big commercial vendors sell tools that make this easy. You can do it with vi, but you don't want to. If JBoss is really compliant and really as good as its hype, the vendors will just incorporate it into their own products, just like they did Apache. Their "value add" still remains, because JBoss does little or nothing to relieve the sheer development burden of distributed J2EE development (aside from good dynamic deployment.)
J2EE is now technically credible and supported by real vendors with real products. Now Sun wants to make it cost effective by allowing JBoss to compete after getting its certification ducks in a row. Wise move.
"What's different about us?"
If you don't know, you're part of the problem.
Here is an interesting link. Short version: Iraqi agents use plastic shredders to execute people. You know, shredders to recycle plastic objects. Big metal drums that grind stuff up.
The 90's were fun. The 90's were made of stuff like this. You know, PDAs and stuff. Don't pick on him. Goofy crap like this can pay for Real Estate.
At the very least Cliff is a barometer. If people still has the leisure to actually care about this we're doing fairly well. Look man, we're about to topple a regime. We have "Ambient Orbs" to fill the commercial breaks.
Anyhow, when I hit the term "Ambient Orb", I immediately recalled "Happy Fun Ball", from SNL. Does anyone else remember hyperventilating over that bit when it was new? Difference is that was parody. "Ambient Orb" you pay for. I bet the guy who wrote the "Happy Fun Ball" skit is kicking himself now.
"If I were a Country trying to defend myself against any military force today that depends on technology"
It ain't that easy to monkey with someone else's satellites. If you radiate, you die. This, of course, precludes jamming. If you're third world, you have no means to put stuff in orbit, or if you do, no means to aim it. GPS satellites and geosync transponders are as far out of Iraq's reach as the Saturn. Forgetaboutit. Even if you're first world, your enemy can move, hide, defend and replace anything you shoot at.
lot of innocent civilians ...have been, are and will be killed by Saddam whether we french around or not.
A man tried to escape to Northern Iraq a few days ago. Bathe Party folks captured him. They tied him to a pole, cut out his tounge and let him bleed to death in public. Guess they were too busy to find an acid vat.
Let's roll.
So, in theory, battlefield porn is the next killer app?
Soldiers usually get plenty of the real thing. Why would they bother with porn?
Of course, this is Iraq... Not like we're liberating Paris. Again.
But, on the other hand, the military is unisex now. Pregnancy was a significant "issue" during GW1.
No, the ceiling is not stupid.
Limiting the physical memory to 40 bits reduces the cost of building other system components, such as chipsets and motherboards, dramatically. Further, 1TB of RAM is sufficient for the current market. That is 1000 1GB parts, to give it some perspective.
As customers begin to approach 1TB requirements, AMD only has to implement more lines. No need for any segmentation hacks. The ISA needs no modification. This is a pragmatic and wise design decision.
64 bits of address space is still very useful without having actual RAM to back it up. It means you can map large quantities of storage into RAM directly. For example; if you have 10TB of disk, you can map all of it into a single virtual address space and address it with simple offsets. Obviously this is useful for large databases.
"That's something you won't get moving to a Linux/AMD solution."
Major vendors (IBM, HP, etc) offer this level of support (and better) for there Linux products right now. Sun does too. When these vendors sell x86-64 CPUs, they will offer the same level of support on day 1. This is understood.
Unlike the Itanium, AMD's 64-bit procs are not emulating 32bit compatibility...
All AMD CPUs are "emulating" the x86 ISA. Athlons decompose x86 instructions and execute them on an essentially RISC core, no? AMD CPUs happen to do it very well, routinely matching higher frequency Intel parts.
Can they provide more bus lines in the future without ISA modifications? If so, then this is a smart design decision. Using only 40 bit addresses reduces the cost of the complete system while providing enough address space.
10 people in about 15 seconds or less
Oh no, a ten round magazine is far more terrifying than that. With armor piercing rounds and careful alignment of your shots it will kill at least 20 people! Of course, any competent shooter will have one round in the chamber in addition to the magazine, so there's another two dead innocents. Naturally one should consider using tiny gas dispensers in the rounds for an area effect. Certainly that would be good for 100 or more! At some point the NRA will finally succeed in producing tiny fission warheads. At that point 10 rounds should be good for wasting several hundred!
Thanks!
...but I suppose as this gets complicated the performance of the SQL queries required to answer questions like (in pseudo-code) SELECT Address WHERE Street Contains "Main Street" becomes difficult...
It shouldn't have to. Some RDBMS systems allow you to optimize locality of rows from multiple tables based on some key. Oracle calls this a "table cluster". Rows from multiple tables are stored together on disk when their keys match across tables. They behave like normal tables in most other respects. Query a particular row from any cluster member and the engine will pick up the related rows automatically in one IO operation.
This is a very efficient way to create table-like structures at runtime. You create an "attribute" table for each significant data-type and cluster all the tables together, then you just create views to make the separate attribute rows appear as a single row in a query.
I can't imagine why it wouldn't apply to XML. I'll bet it's done this way in real XML database implementations.
These old news stories are hard to recover because even Google doesn't preserve everything forever...
e 9.html
However, here's a URL to a page that mentions a case in Italy:
http://www.angelfire.com/on2/oddnews/issu
Here is an article with a bunch of cases. In the Hamburg case, the man died and remained undiscovered for half a decade.
http://melvindurai.com/dead.htm
"I think most of the credit should go to the 386 implementors"
Intel no more invented TLBs than Linus invented fork(). The x86 ISA and the Unix design are both the result of countless prior efforts. They evolved symbiotically over many generations, using many hardware platforms. Attempting to ascribe any particular percentage of credit to one or the other is naive. It took decades of effort to arrive at the contemporary model. The truth is that IBM implemented most of the significant features of multitasking virtual memory systems, both hardware and software, before Linus was born.
There's a german architect named Albert Speer who has done some work for the german government on this idea, though I understand it to be quite controversial.
Every now and they someone discoverers a pensioner somewhere in the fatherland that's been dead in their home for a couple years. It seems that one can arrange things so that the government payouts are deposited in an account, and all your recurring debts are automatically paid from there. If you don't have friends or family that care enough to visit, you're free to die and go unnoticed indefinitely.
Think of it... somewhere in Berlin or Hamburg there are skeletons propped up in chairs with bowls of chips in theirs laps, faithfully watching to tube. Now all we need is apartments that last hundreds of years. At some point a certain percentage of units will have 200 year old occupants that never come out.
BTW, this isn't urban legend. It's been widely reported on several occasions.