What if a CPU had a 99.8% accuracy when switching gates ? Well, there'd be a chance of 90% that at least one in 1150 switches would go wrong, or 50% for 346 switches.
(God, I just realised that the accuracy of a condom is much less than that...)
What sane person would store a massive amount of data with the on-disk format being XML
Don't get it wrong... As you said, no sane person would use the XML format for storage of massive data. However nothing's wrong with using XML for external representation and querying (see XQuery for example).
The whole point with XML is interoperability . When designing a distributed application, one could choose from:
IIOP/CORBA (or variants like Java/RMI, etc.): theoretically very good interoperability, but practically almost none when you use tools from different vendors
design a custom binary protocol. Most of these designs are short-sighted - making them extensible is not an easy task. Moreover, most of them adopt an ostrichish attitude towards both byte ordering and character encodings
use XML: built-in extensibility, extremely good interoperability & support for different encodings. Certainly more of a bandwidth hog than the previous two, however, as we all know, the battle between bandwidth and processing power was won by bandwidth. When bandwidth is the bottleneck, one could still use standard HTTP compression to alleviate the problem.
XML-RPC is nothing but interoperability taken to the extreme: XML is the packaging format, mostly because any architecture/os can properly decode it, and HTTP is the carrier, because it can pass all proxies, and, again, almost everything understands HTTP
As far as configuration files are concerned, one extra reason for having XML as format is that it's cheaper & faster to use a DOM parser than to write your own...
In order to be acceptable from a consumer's point of view, such a car would have to have batteries... Even in a desert you still wouldn't want to be limited to day-only driving.
Batteries on the other hand are very heavy. They account for more than 50% of the weight of a regular electric car. The energy required to move the batteries makes such a solar-powered car infeasible.
As mentioned in another post, most of the teams only improved on aerodynamics & weight. So, I'm asking: what's the point of this competition ?
Just wanted to remind you that deciding at compile time if a given program will go wrong (division by zero, memory faults, infinite loops) or not is an undecidable problem for any Turing-complete language. That certainly limits the "smartness" of a compiler. Detecting typos is an useful feature, but certainly you can't rely on the compiler to find higher level bugs.
Runtime checking is useful, however I'd rather use a tool like Purify/CheckerGcc/Insure++ with gcc and standard C/C++ than switch to a new language.
Let's get real ...
on
Looking At Gobe
·
· Score: 4, Insightful
The Word.doc file format has not yet been mastered, no powerpoint compatibility, poor lettering on Glyphs, no sound or video.
There's nothing more important in the Office world than compatibility M$ file formats. Which reminds me that the current antitrust settlement doesn't say anything about opening file formats.
Back to StarOffice & powerpoint viewers (thanks god there's Wine!)...
There is nothing in this paper to convince me that such a model would work for a capitalist enterprise. The comparison between the Linux Project and Microsoft is absurd, as the first is a volunteer-based non profit project, while the second is a company. Models that work for a class of projects don't necessarily work for others.
Moreover, statements like:
If the automobile industry started taking on an open source development model with sharing across companies and countries, the cost and prices would eventually drop, innovation and development would speed up and exceptional features would be shared across many makers and models. The auto industry could finally come up with the safe, clean energy car.
are simply hallucinogenic.
Remember, the difference between communism and capitalism is that sharing is mandatory in the first and optional in the second.
The author of the article forgot to mention the amount of RAM on the test machines. When publishing the results of a benchmark one is supposed to include all configuration details so that others can replicate it. What's the use of a benchmark if it's not replicable ? The amount of RAM is certainly an important factor for overbloated applications like OfficeXP.
I'd suggest Infoworld to take a look at sites like www.firingsquad.com to learn how to publish benchmarks.
It is pretty obvious that cookies are used for 2 main purposes: session tracking and navigation tracking. While the first is a legitimate use, the second is one of the worst violations of privacy EVER.
The real problem is that the most popular browsers only allow you to block/unblock cookies globally, therefore if you want privacy, the sites that rely on cookies won't work. Even scarier is the fact that, the more popular a site, the greater the chance that it requires cookies (personal observation). When given a choice (one might argue that it's not really a choice, since cookies are enabled by default) between lack of functionality and lack of privacy, most of the users prefer lack of privacy.
For an OS to become mainstream (as the author of the article implies), it needs two things:
1. Good support for x86 hardware (large variety of peripherals)
2. Applications (desktop, server), satisfying the needs of a large number of the users.
Without these - it's nothing but a niche OS.
It took Linux a good number of years to get passing grades for #1 and #2. It's true that the development for Cessium started a while ago, however nothing indicates that they've reached a critical mass
More than that, there is very little room in the market for a revolutionary OS. As a matter of fact revolutionary OSes were one of the easiest ways of wasting money in the last decade (e.g: OS/2, Plan9, BeOS...).
I do think it's a great research OS. Acceptance, however, is a totally different story
A program that almost runs is like a plane that almost flies
Regardless of what Juliard says, WINE is mostly used as an app-level emulator. The problem is that WINE can't properly run most of the popular Windows applications, and, at the same time, alternatives like Win4Lin do a much better job at that.
- All the sales of all Linux Games are dwarfed by
the sales of a single, average, Windows game
- While commercial Linux 2d games are generally more stable than their Windoze counterparts, there are still a lot of problems in the 3d area, and the future is bleak (VA layoffs, etc.)
Anyway, it's a good step forward, even though it might not be a commercial success.
I'm not criticizing the app developers, what I'm saying is that the kde libraries should allow for a greater degree of compatibility. Of course, everybody hates split dev branches, however compatibility can be insured in other ways (e.g. macros, polymorphism). The kernel people, for instance, managed to do a very good job as far as source-level compatibility is concerned (and think about the number of platforms supported and the kernel versions!)
Now, that the Alpha is here, I think most of developers will start porting their apps to 3.0, and guess what, we'll have very few new app releases for 2.2.1 (not to mention the fact that most of the rpms of KDE apps that I download are difficult to install - dependencies are hard to satisfy and most of the time building the source rpm fails)
My clear impression is that their is huge gap between the KDE itself and the apps developed for it. We really need more stability (compatibility) and less cool features in the future.
Does this mean that all new applications and new versions of the existing KDE applications will be targeted towards KDE 3.0 ? Long before KDE 2.0 stable was released, all new app releases worked only on KDE 2.0 betas. Users had to choose between an old version of an app on a stable system and a new version on an unstable system.
This is as irrelevant as the MIPS of a CPU. We now laugh when seeing old papers where MIPS was used as a real indication of processor speed, however when it comes to operating systems, we use fundamentally flawed benchmarks. The speed of a single feature of the operating system has very little relevancy, the only thing that really matters is the overall response time (per program of per transaction)
The question is which is more flawed: this benchmark or Mindcraft's one
There is only one real problem with LCDs: their colors are generally not as vivid (saturated) as the ones produced by a CRT screen. Most of them lack proper color calibration
Out of the 300 TLDs the vast majority are geographic. The question itself is politically incorrect, simply because it's very unlikely that any university would want ALL the 300+ TLDs (drexel.sz - drexel dot Swaziland - that would be really cool!). It's a dirty trick to make the university look like the "bad and greedy" guy.
The question is: what has the University done wrong ?
Commercials are just commercials... most people just ignore them. Having Windows as the OS on those computers is much worse, though, as it inoculates habit. Consumer education in other words.
You're not actually locked into using Java. Many languages can be compiled into java bytecode, the most notable beeing Python (Jython) and Scheme. The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.
Slashdot Mirror
What if a CPU had a 99.8% accuracy when switching gates ? Well, there'd be a chance of 90% that at least one in 1150 switches would go wrong, or 50% for 346 switches.
(God, I just realised that the accuracy of a condom is much less than that
The Raven.
I'm sure it took the terorists a lot of research time to find the location of the Twin Towers ...
The Raven.
Don't get it wrong
The whole point with XML is interoperability . When designing a distributed application, one could choose from:
IIOP/CORBA (or variants like Java/RMI, etc.): theoretically very good interoperability, but practically almost none when you use tools from different vendors
design a custom binary protocol. Most of these designs are short-sighted - making them extensible is not an easy task. Moreover, most of them adopt an ostrichish attitude towards both byte ordering and character encodings
use XML: built-in extensibility, extremely good interoperability & support for different encodings. Certainly more of a bandwidth hog than the previous two, however, as we all know, the battle between bandwidth and processing power was won by bandwidth. When bandwidth is the bottleneck, one could still use standard HTTP compression to alleviate the problem.
...
XML-RPC is nothing but interoperability taken to the extreme: XML is the packaging format, mostly because any architecture/os can properly decode it, and HTTP is the carrier, because it can pass all proxies, and, again, almost everything understands HTTP
As far as configuration files are concerned, one extra reason for having XML as format is that it's cheaper & faster to use a DOM parser than to write your own
The Raven.
In order to be acceptable from a consumer's point of view, such a car would have to have batteries ... Even in a desert you still wouldn't want to be limited to day-only driving.
Batteries on the other hand are very heavy. They account for more than 50% of the weight of a regular electric car. The energy required to move the batteries makes such a solar-powered car infeasible.
As mentioned in another post, most of the teams only improved on aerodynamics & weight. So, I'm asking: what's the point of this competition ?
The Raven.
Just wanted to remind you that deciding at compile time if a given program will go wrong (division by zero, memory faults, infinite loops) or not is an undecidable problem for any Turing-complete language. That certainly limits the "smartness" of a compiler. Detecting typos is an useful feature, but certainly you can't rely on the compiler to find higher level bugs.
Runtime checking is useful, however I'd rather use a tool like Purify/CheckerGcc/Insure++ with gcc and standard C/C++ than switch to a new language.
The Word .doc file format has not yet been mastered, no powerpoint compatibility, poor lettering on Glyphs, no sound or video.
...
There's nothing more important in the Office world than compatibility M$ file formats. Which reminds me that the current antitrust settlement doesn't say anything about opening file formats.
Back to StarOffice & powerpoint viewers (thanks god there's Wine!)
The Raven
There is nothing in this paper to convince me that such a model would work for a capitalist enterprise. The comparison between the Linux Project and Microsoft is absurd, as the first is a volunteer-based non profit project, while the second is a company. Models that work for a class of projects don't necessarily work for others.
Moreover, statements like:
If the automobile industry started taking on an open source development model with sharing across companies and countries, the cost and prices would eventually drop, innovation and development would speed up and exceptional features would be shared across many makers and models. The auto industry could finally come up with the safe, clean energy car.
are simply hallucinogenic.
Remember, the difference between communism and capitalism is that sharing is mandatory in the first and optional in the second.
The Raven.
The author of the article forgot to mention the amount of RAM on the test machines. When publishing the results of a benchmark one is supposed to include all configuration details so that others can replicate it. What's the use of a benchmark if it's not replicable ? The amount of RAM is certainly an important factor for overbloated applications like OfficeXP.
I'd suggest Infoworld to take a look at sites like www.firingsquad.com to learn how to publish benchmarks.
The Raven.
It is pretty obvious that cookies are used for 2 main purposes: session tracking and navigation tracking. While the first is a legitimate use, the second is one of the worst violations of privacy EVER.
The real problem is that the most popular browsers only allow you to block/unblock cookies globally, therefore if you want privacy, the sites that rely on cookies won't work. Even scarier is the fact that, the more popular a site, the greater the chance that it requires cookies (personal observation). When given a choice (one might argue that it's not really a choice, since cookies are enabled by default) between lack of functionality and lack of privacy, most of the users prefer lack of privacy.
The Raven
For an OS to become mainstream (as the author of the article implies), it needs two things:
...).
1. Good support for x86 hardware (large variety of peripherals)
2. Applications (desktop, server), satisfying the needs of a large number of the users.
Without these - it's nothing but a niche OS.
It took Linux a good number of years to get passing grades for #1 and #2. It's true that the development for Cessium started a while ago, however nothing indicates that they've reached a critical mass
More than that, there is very little room in the market for a revolutionary OS. As a matter of fact revolutionary OSes were one of the easiest ways of wasting money in the last decade (e.g: OS/2, Plan9, BeOS
I do think it's a great research OS. Acceptance, however, is a totally different story
Raven
A program that almost runs is like a plane that almost flies
Regardless of what Juliard says, WINE is mostly used as an app-level emulator. The problem is that WINE can't properly run most of the popular Windows applications, and, at the same time, alternatives like Win4Lin do a much better job at that.
gcc 3.0 needs "major bugfixes", not minor ones, especially in the c++ compiler.
- All the sales of all Linux Games are dwarfed by
the sales of a single, average, Windows game
- While commercial Linux 2d games are generally more stable than their Windoze counterparts, there are still a lot of problems in the 3d area, and the future is bleak (VA layoffs, etc.)
Anyway, it's a good step forward, even though it might not be a commercial success.
Following linux API's are emulated now:
- exit, read, write, fcntl, getpid, getuid, getgid, getegig, geteuid, brk, mmap, munmap
Where's open?
I'm not criticizing the app developers, what I'm saying is that the kde libraries should allow for a greater degree of compatibility. Of course, everybody hates split dev branches, however compatibility can be insured in other ways (e.g. macros, polymorphism). The kernel people, for instance, managed to do a very good job as far as source-level compatibility is concerned (and think about the number of platforms supported and the kernel versions!)
Now, that the Alpha is here, I think most of developers will start porting their apps to 3.0, and guess what, we'll have very few new app releases for 2.2.1 (not to mention the fact that most of the rpms of KDE apps that I download are difficult to install - dependencies are hard to satisfy and most of the time building the source rpm fails)
My clear impression is that their is huge gap between the KDE itself and the apps developed for it. We really need more stability (compatibility) and less cool features in the future.
Does this mean that all new applications and new versions of the existing KDE applications will be targeted towards KDE 3.0 ? Long before KDE 2.0 stable was released, all new app releases worked only on KDE 2.0 betas. Users had to choose between an old version of an app on a stable system and a new version on an unstable system.
As far as a computer is concerned, everything is a number
This is as irrelevant as the MIPS of a CPU. We now laugh when seeing old papers where MIPS was used as a real indication of processor speed, however when it comes to operating systems, we use fundamentally flawed benchmarks. The speed of a single feature of the operating system has very little relevancy, the only thing that really matters is the overall response time (per program of per transaction)
The question is which is more flawed: this benchmark or Mindcraft's one
(this is actually a book by Benjamin Kuras)
I'm just wondering if it's possible to measure the speed of the spacecraft relative to Earth using the Doppler effect.
There is only one real problem with LCDs: their colors are generally not as vivid (saturated) as the ones produced by a CRT screen. Most of them lack proper color calibration
Out of the 300 TLDs the vast majority are geographic. The question itself is politically incorrect, simply because it's very unlikely that any university would want ALL the 300+ TLDs (drexel.sz - drexel dot Swaziland - that would be really cool!). It's a dirty trick to make the university look like the "bad and greedy" guy.
The question is: what has the University done wrong ?
Commercials are just commercials ... most people just ignore them. Having Windows as the OS on those computers is much worse, though, as it inoculates habit. Consumer education in other words.
You're not actually locked into using Java. Many languages can be compiled into java bytecode, the most notable beeing Python (Jython) and Scheme. The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.