Sure, that's just good business sense for them - but it also helps reduce the number of strays on the streets, and gets people used to sterilizing their pets.
The first thing to understand is that eiffel's design-by-contract features sound a lot nicer than they are. They could be very good, but most (all?) current compilers pretty much just translate them to a bunch of run-time precondition and postcondition assertions, which I find pretty yawn-worthy. Of course, I'm *VERY* far from an Eiffel expert, so feel free to politely correct me if the above is bunk.
I've been happy ensuring that:
- Every non-trivial object has a private invariant() method that is called at the completion of its ctor and any non-const qualified method. This helps to ensure that the object is internally consistent. It's expensive though so it's something I usually make a build-time option. - Every method asserts its pre- and post- conditions. - Extensive sanity checking is preformed wherever else it makes sense.
in my C++ code, and doing so has prevented more than a few bugs. That said, *nothing* is as effective in my experience as writing comprehensive unit tests that consider all the corner cases you can think of, combined with coding using safe and automatic memory management (not necessarily a gc; good use of automatic stack objects, auto_ptr, std::tr1::smart_ptr / boost::smart_ptr and other devices for tracking and managing memory ownership and allocation can be as good or better for many use cases).
My mistake - that post is not correct. It appears to actually be using JavaScript as supported by Adobe reader to automatically launch a link. Still, in my view, not a big deal (and my Adobe Reader asks for confirmation anway) but somewhat more valid.
The first "vulnerability" is the ability to have clickable web links in a pdf. It's a standard feature of the PDF document language, and all conforming viewers should support it. I'd be surprised if evince doesn't, but most of the other free viewers are too primitive.
In my view this claim is idiotic anyway. I just found a giant security hole in HTML where if they view my page or email with a link and if they click on it, it might take them to a malicious site.
I used to agree with the person you're responding to. These days, I tend to take your view - that understanding the guts is IMPORTANT.
Part of what convinced me was seeing the total lack of understanding of the critical difference between heap and stack memory in the C++ programs I was reading. Some people didn't even seem to know you could allocate objects on the stack (java users? It looked like it, but they'd never used Java it turned out) so I'd see code like this:
MyObj * o = new MyObj(...); o->doSomething(); delete o;
which is not ALWAYS stupid... just almost always when compared to:
MyObj().doSomething();
I also had some eye-opening experiences with how a failure to understand the difference between byte strings and unicode strings can lead to amazing code horrors - including images being stored in unicode strings by shoving each byte into a unichar... because the strings were implicitly shared and thus easy to work with.
It's crucial to understand how to understand and design systems at a high level, and it's equally critical to understand how they work internally. The better I understand the lower levels of functionality understanding the systems I use, the better a programmer I become in the higher levels I actually work in day to day.
I'd love to see someone combine these two approaches by starting students on something like Python or maybe some RAD in one unit while hand-coding asm in another, then drilling down and up until the two meet somewhere near C++.
It's important to understand that it's not purely electronic. The forms are delivered to homes by hand and an estimate of the number of people expected to be there that evening is collected. The forms have a unique ID code on them that must be used when submitting online.
These measures make it a LOT harder to submit garbage census results en-masse. Not impossible, I'm sure, but I think it'd be pretty hard to pull off major bogus submissions, let alone undetectably.
That said, I'd love to see what Bruce Schneider could spot in terms of security issues...
So, companies selling open source products are a "silicon valley phenomenon". Surprise surprise.
The map of developers, which would be much more interesting, is impractical to create. I've seen partial maps for a number of projects, though, and they certainly don't show the same distribution as the referenced article. I just went looking for a GNOME one but the only one I could find was on frappr, and was clearly so incomplete as to be nigh useless (_nobody_ in Australia; only two in the US, etc).
A more personal example is the Scribus team, which has no members in the USA. The core developers are in Germany, France, Luxembourg, Czechoslovakia, Finland, and Australia. Of those, one originally lived in the US but moved, and one more used to live in Australia but moved. Hardly "silicon valley". The contributors see more US involvement, but not a huge amount more, and the translation teams are obviously incredibly internationally distributed. Our user base is also very international, as Scribus's translations and support for other languages is its main advantage (beyond cost) over the big DTP names.
Auckland City in New Zealand (!!) has been doing this for a fair while now. Given that I'll be amazed if it's not already all over the world. Heck, when I was in France I was able to hire a bicycle with an SMS.
That's not to say it's uninteresting or not useful (rather the opposite); rather it's just old news.
Now, either Seagate shipped me an unofficial experimental laptop disk with built-in nuclear reactor to power the spindle motor, or I screwed up. I see no giant smoking hole where the platter left for orbit when I turned my laptop, so I figure I won't be selling this off to the competition anytime soon.
I agree - most laptop disks are awful, and an incredible brake on otherwise speedy systems. I'm always amazed to see a 2GHz Core Duo laptop shipped with a 5400RPM (sometimes even 4200RPM) disk.
Mine was, for example. I spent the extra 7% to add an after-market 72kRPM SATA disk (80gb vs 120GB, but hey, the 120GB is still useful in an external enclosure) and the laptop's performance about doubled for many tasks. It's worth every cent. The fact that Apple offer 72kRPM disks in their laptops is one of the biggest reaons, if not the only reason, why they get such excellent benchmark scores, and it astounds me that few other manufacturers are doing it.
It's an accounts and newspaper bookings system. It's writen in a "4GL" called Plain English in 1991. The company that created the runtime had ceased to exist long before the app was writen - we're using Plain English from 1893. I've never been able to comprehend how anybody could choose a proprietary 4GL from a long defunct company for the basis of their new mission-critical app... especially when it's not very good. I suspect the situation boiled down to the "developer" being incapable of using anything else - he's more of a business systems analyst and accountant than a developer, and my god does it show in the code.
The modern equivalent would be a business system written in VBA on top of Access 1.0 (presuming it had VBA), now, in 2006.
More info in response to another poster too, in case you care.
I inherited this abominable situation and have been trying to find a way to get the business out of it for some time. Doubly so since the creator of the software is becoming more and more unrealiable (think: errattic, alcoholic, drops out of touch for months, etc) and the system needs fixes periodically to keep it running because of the incredibly crap underlying runtime and some bad decisions by the developer of the system its self.
It's being replaced, but because it's so neatly tailored to the business and so important that's a slow process. In the mean time... I get to maintian OpenServer. I think OpenServer is by far and away the best part of the situation, but that doesn't make it nice.
I don't have the source code. Trust me, if I did, I'd have ported it quite some time ago. As for not having the source... the person making the decisions when the app was written just wasn't aware of the issues.
The problem is in fact not the application its self - that was custom built and we do have the source - but the runtime it sits on. It's an early database-integrated 4GL called Plain English. The company that wrote the runtime is long dead. In fact, it was out of business more than eight years before the system developed on top of the runtime was developed, and I've never been able to understand how on earth they chose to use this ancient 4GL for the project.
I've actually written a replacement runtime based on the documentation I have on Plain English, but it looks like the code we have relies on quite a bit of undocumented behaviour. It's not well enough written to handle unexpected issues or error conditions successfully - in fact I'd describe it as hideous undocumented spaghetti from hell - so testing is awfully painful. Given the reliability level required it's not a practical approach, and even if it were, I'd just be maintaining hideous spaghetti from hell on top of a new runtime. Um, yay.
Did I mention the integrated database without transaction support that is corrupted if a client unexpectedly disconnects? Same issue with telnet disconnects and the old dumb terminals (no longer used) being turned off - it's just crap software. What about the lovely code-in-database setup that is prone to corruption if the incredibly flakey custom editor runs into any issues? Yes, Plain English is clearly the height of modern software development...
The system is being replaced, but in the mean time, I have to keep OpenServer kicking along. Ugh.
OpenServer (at least v5.0.5 which I have) is weird. It's better documented than Linux is and can ever hope to be - the docs are more consistent, more accurate, more complete, and better written. It's also incredibly stable in most ways - but with a few REALLY annoying quirks. As it's also stable in the same way a fossil is (What, buy and upgrade? Get bent), that's frustrating. It also has some incredibly annoying limitations, a set of developer tools so bad they boggle the mind (and the alternatives aren't great either - haven't got Skunkware's gcc WORKING yet), and some basic services we're used to just being there... well... aren't. Oh, and printing on SCO is one of the worst messes I've ever had the misfortune to work with - it makes Linux printing look like heaven, and it's pretty awful too. If you now feel the need to scour your eyes with steel wool, you're not alone.
I maintain an OpenServer box for work only because of a legacy app that requires it. Well, strictly, the app requires Microsoft Xenix to run - it's from 1983 (!!) - but SCO OpenServer's XENIX kernel personality does the trick with a few quirks. OpenServer at least supports PCI, >16MB RAM, and >512MB disks, unlike XENIX. (OpenServer 5.0.5 actually supports up to 2TB disks/arrays, >137GB ATA disks, etc. Not bad for an OS from 1995). If it weren't for that need - which Linux can't satisfy even with the defunct ibcs project - I'd be rid of OpenServer in an instant. Linux 2.6 isn't as stable as I'd like, but that's worth it... and there's always Solaris as an alternative.
I can't imagine anybody buying OpenServer now. Its only purpose is legacy support. Unixware doesn't even have that. Before Sun released Solaris for free, they had a tiny sliver of hope from people who need more stability than Linux provides... but with a free Solaris, they're just doomed. RHEL and so on help a fair bit with regards to stability in Linux too - something which also doesn't help SCO in the slightest.
Even if their technology wasn't obsolete crap, who on earth would buy from a company that sues its own customers? Oh, wait, I use Microsoft software at work and I'm well aware of its involvement in the BSA & BSAA so that's no argument at all... but the obsolete crap point holds.
First, mobile phones do have extremely high frequency chips in them. They have to in order to recieve and process the high frequency signals they deal with. Those high frequency chips are a fairly large part of their power draw, too - yet their draw is *tiny* compared to even the simplest CPU of that clock. Remember that clock speed means very little without a consideration of the number of transistors on the chip, energy leakage rates, and lots more I know nothing about.
You're making the erroneous equation that "chip" == CPU, which is far from the case. A phone's CPU may be clocked much lower. Even if it's integrated with the RF chip (I'm not sure this is ever done, is it?), the RF processing parts will be clock-multiplied or the CPU parts will be clock-divided to ensure sensible running frequencies.
I think you'll also find that, contrary to the assumptions made by most posters here on/., this chip is a very fast very simple unit - not a large microprocessor. I'd guess they're looking into ultra-high-speed signal processing (hence the mobile phone analogy) rather than computer CPUs here.
I've long wished that Firefox would support LDAP+TLS or WebDAV+TLS (with client certificates) for storing at least bookmarks, if not history. It's amusing that Google seems to have done it for them - the downside being that I can't use my own servers, I have to use Google. I'll still bite.
To be honest, though, what'd be REALLY exciting would be a similar tool for Thunderbird that enabled a secure writeable server side (pref. LDAP) address book, not just the limited read-only LDAP address book support it currently has. If their calendar app added WebDAV+TLS or HTTPs WebDAV remote calendar storage, it'd start to feel like an app made for people who (*gasp*) use more than one computer.
Maybe Google's move here will show the mozilla folks that people are interested in these features.
In fairness, it *does* work using Firefox. So they're doing better than usual. Contrast to Windows Live Safety Centre (http://safety.live.com) which breaks if you even try to do anything in firefox (let alone anything else).
You got it. Like Java, C#.Net can be fast and efficient. Like Java, if you add Swing (the C# equivalent is Windows Forms) into the mix it becomes a bloated pig in a hurry. Like Java, it takes plenty of skill and thought to write an app that doesn't take a week to load, so you actually can't hire monkeys for programmers.
To be quite frank, the ATi drivers are awful under Windows too. The ATi control center manages to take 25s to load on my 2GHz Core Duo laptop with 2GB of RAM and a 7200rpm hard disk. That's equivalent to an awfully grunty desktop. For all that, it doesn't even do very much, has a terrible UI, doesn't work correctly when Windows is set to use the correct screen DPI not pretend it's a 72dpi display (pathetic for a video card mfgr), and is a bit flakey to boot.
The ATi drivers are absolutely crap no matter what platform you're on.
In theory that's true. In practice, DRM can be made effective enough by making it too difficult to crack for most users. By designing to reduce the chance of breaks across whole models or classes of device (unique keys, anti-tampering, etc etc) and just generally working hard to make it a royal pain to crack each system, they get most of what they want: the average user stops trying and gives up.
Now, in most cases it only takes one break for some file/show/whatever to be made available for everybody. So long as we assume devices can still play "unprotected" content, that's enough to break the effectiveness of the DRM but still make everybody's lives miserable. Everybody loses! I suspect that's what we're headed towards, and the media outfits will keep on using the isolated breaks as an argument for stronger and stronger "protection" and legislative support, then to lock down "unprotected" content, etc etc.
I'm hoping it'll all come crashing off the rails when someone wakes up and sees some sense, but it's not going to do so in a hurry, and the trip in the mean time won't be fun.
The ODF Format isnt' a word processor format or spreadsheet format. It's an "office" document container with subformats for a number of major tasks. If they want it to be future proof against the changing needs of users and developers, it needs to be flexible and extensible both within the subformats, and to allow new subformats. Currently, it doesn't seem to be as extensible as it might ideally be, or as extensible as the MS offering (weird, eh?).
Who would've thought when MS Word 2.0 came out that macros (for all their evils) might be a mandatory thing to be able to store in a document? Heck, even images. Who knows what we'll need in future, but I'd prefer a format that can handle whatever gets thrown at it, not one that must be revised each time new requirements arise.
The biggest flaw in the ODF standard as its stands is that it doesn't really use XML's capabilities for, well, extensibility.
ODF is XML, so by default ODF has this ability. In addition, ODF has partial support of W3C XForms.
In theory, using XML would be enough to guarantee useful extensibility. In reality that's not so. An application often uses XML as an on-disk format, but doesn't preserve its structure or contents when loading the document into memory, instead converting the document into its own native structures. To save the document, the in-memory data structures are serialized to disk. Unless the program takes great pains to preserve any associated XML data that it doesn't understand, that data is lost. OpenOffice makes no such effort.
There are a couple of ways to do it so that you get to use XML properly, not just as a slightly friendlier on-disk format. One is to work in-memory with a DOM constructed from your XML file. That can work very well, but can also get slow and cumbersome. It can also be very, very memory expensive with large documents.
Another way is to work with the document fairly normally, but preserve any XML structures that aren't understood by associating them with your normal objects. These then get serialized out again on saving, still associated with the right objects; they're deleted when the object is, and so on. It's generally not as nice as using a DOM, but does the job, and if you provide suitable APIs to plugins etc they can still work with this data.
The worst way is to just discard anything you don't explicitly understand on input, and that's what OO.o does. The ODF spec permits apps to do this, and in fact doesn't even suggest that they might do anything else. If the single biggest implementor of the spec will discard all XML that it doesn't directly implement, the format isn't really using XML all that well to my mind. The format specification needs to require that applications preserve foreign markup in order to comply with the spec; failure to do so means one can never know if any given app will strip out parts of your document.
I do know about the XForms support, and I find it very interesting. That said, I just think they need to recognise that they just can't anticipate every possible thing that people might need from the format, and plan for really solid extensibility, rather than just trying to add support for the technology-of-the-day as they go along. I'm astonished and impressed that Microsoft "gets" this, while the ODF folks don't really seem to.
Yep, MS Office loads some code at start-up, or at least older versions did. I can't actually find any running programs or services with Process Explorer or Autoruns to suggest that that's still true in Office 2003, and the first-time load time is quite a bit longer than subsequent executions. I wouldn't be surprised if it just pre-reads the DLLs from disk into cache and leaves it at that (just like most Linux distros now precache the login environment and common programs during boot). Anyway, in the Windows 95 days, when 4MB of RAM was a lot, that preloader was a giant resource hog. I see no evidence on my system that it's still even detectable. Of course, my system with XP running, firefix, thunderbird, and a leaping mound of OEM crap weighs in at a little over 200MB of memory used, so I'm not too stressed. Quitting thunderbird freed 70MB anyway (hooray for memory-efficient IMAP clients?).
My experience is that in real-world use MS Office just uses less memory and CPU time to accomplish tasks than OO.o does. MS Office is certainly not lean compared to some of the lighter, smaller and less functional options around, but I've found it to be much less hard on a system than OO.o.
Of course, now I have a 2x2GHz laptop with 2GB of RAM, so I don't really care;-) I just think the "Office is bloated" argument is old, tired, and no longer relevant due to changes in systems and the programs concerned. Heck, I think these days it might be smaller than emacs;-)
While your comment doesn't really deserve the dignity of a reply (especially since you posted AC), I'm going to waste some time and do so anyway.
The simplest reason to want to preserve your own markup is to integrate with other systems. Here's a simplistic example: A content management system may want to store the identity of a document in the document in such a way as that it can be reognised as the same document when re-imported into the CMS after someone's been working on it on some disconnected laptop. Existing metadata may not offer that facility.
Another good case is a plug-in that adds significant functionality to the application and needs to store its data in the document, have it travel with the document, and have its data associated with specific parts of the document. Consider a bibliography editor - if you delete the text with the reference, the editor needs to be able to tell that's happened and not output the associated reference in the full bibilography. Currently such tools maintain their own databases and/or use opaque blobs in the document for this, but these approaches aren't very good - in particular they mean that if the document is edited by a tool that doesn't have the bibliography editor, the information can be lost or damaged.
That's a simplistic example, but in the broader sense it comes down to wanting to be able to do things with a format beyond those that the original designers explicitly considered. Imagine if we still had to use X11 as it was written originally? What a mess. Thankfully, X11 is extensible and well designed so that additions the original designers didn't imagine can be added over time.
A generic, universal "office" document format needs to satisfy that requirement too.
Slashdot Mirror
Sure, that's just good business sense for them - but it also helps reduce the number of strays on the streets, and gets people used to sterilizing their pets.
The first thing to understand is that eiffel's design-by-contract features sound a lot nicer than they are. They could be very good, but most (all?) current compilers pretty much just translate them to a bunch of run-time precondition and postcondition assertions, which I find pretty yawn-worthy. Of course, I'm *VERY* far from an Eiffel expert, so feel free to politely correct me if the above is bunk.
I've been happy ensuring that:
- Every non-trivial object has a private invariant() method that is called at the completion of its ctor and any non-const qualified method. This helps to ensure that the object is internally consistent. It's expensive though so it's something I usually make a build-time option.
- Every method asserts its pre- and post- conditions.
- Extensive sanity checking is preformed wherever else it makes sense.
in my C++ code, and doing so has prevented more than a few bugs. That said, *nothing* is as effective in my experience as writing comprehensive unit tests that consider all the corner cases you can think of, combined with coding using safe and automatic memory management (not necessarily a gc; good use of automatic stack objects, auto_ptr, std::tr1::smart_ptr / boost::smart_ptr and other devices for tracking and managing memory ownership and allocation can be as good or better for many use cases).
--
Craig Ringer
My mistake - that post is not correct. It appears to actually be using JavaScript as supported by Adobe reader to automatically launch a link. Still, in my view, not a big deal (and my Adobe Reader asks for confirmation anway) but somewhat more valid.
The first "vulnerability" is the ability to have clickable web links in a pdf. It's a standard feature of the PDF document language, and all conforming viewers should support it. I'd be surprised if evince doesn't, but most of the other free viewers are too primitive.
In my view this claim is idiotic anyway. I just found a giant security hole in HTML where if they view my page or email with a link and if they click on it, it might take them to a malicious site.
*yawn*
I used to agree with the person you're responding to. These days, I tend to take your view - that understanding the guts is IMPORTANT.
... just almost always when compared to:
... because the strings were implicitly shared and thus easy to work with.
Part of what convinced me was seeing the total lack of understanding of the critical difference between heap and stack memory in the C++ programs I was reading. Some people didn't even seem to know you could allocate objects on the stack (java users? It looked like it, but they'd never used Java it turned out) so I'd see code like this:
MyObj * o = new MyObj(...);
o->doSomething();
delete o;
which is not ALWAYS stupid
MyObj().doSomething();
I also had some eye-opening experiences with how a failure to understand the difference between byte strings and unicode strings can lead to amazing code horrors - including images being stored in unicode strings by shoving each byte into a unichar
It's crucial to understand how to understand and design systems at a high level, and it's equally critical to understand how they work internally. The better I understand the lower levels of functionality understanding the systems I use, the better a programmer I become in the higher levels I actually work in day to day.
I'd love to see someone combine these two approaches by starting students on something like Python or maybe some RAD in one unit while hand-coding asm in another, then drilling down and up until the two meet somewhere near C++.
It's important to understand that it's not purely electronic. The forms are delivered to homes by hand and an estimate of the number of people expected to be there that evening is collected. The forms have a unique ID code on them that must be used when submitting online.
These measures make it a LOT harder to submit garbage census results en-masse. Not impossible, I'm sure, but I think it'd be pretty hard to pull off major bogus submissions, let alone undetectably.
That said, I'd love to see what Bruce Schneider could spot in terms of security issues...
So, companies selling open source products are a "silicon valley phenomenon". Surprise surprise.
The map of developers, which would be much more interesting, is impractical to create. I've seen partial maps for a number of projects, though, and they certainly don't show the same distribution as the referenced article. I just went looking for a GNOME one but the only one I could find was on frappr, and was clearly so incomplete as to be nigh useless (_nobody_ in Australia; only two in the US, etc).
A more personal example is the Scribus team, which has no members in the USA. The core developers are in Germany, France, Luxembourg, Czechoslovakia, Finland, and Australia. Of those, one originally lived in the US but moved, and one more used to live in Australia but moved. Hardly "silicon valley". The contributors see more US involvement, but not a huge amount more, and the translation teams are obviously incredibly internationally distributed. Our user base is also very international, as Scribus's translations and support for other languages is its main advantage (beyond cost) over the big DTP names.
--
Craig Ringer
Auckland City in New Zealand (!!) has been doing this for a fair while now. Given that I'll be amazed if it's not already all over the world. Heck, when I was in France I was able to hire a bicycle with an SMS.
That's not to say it's uninteresting or not useful (rather the opposite); rather it's just old news.
Now, either Seagate shipped me an unofficial experimental laptop disk with built-in nuclear reactor to power the spindle motor, or I screwed up. I see no giant smoking hole where the platter left for orbit when I turned my laptop, so I figure I won't be selling this off to the competition anytime soon.
Good catch. Too used to 10k RPM disks.
I agree - most laptop disks are awful, and an incredible brake on otherwise speedy systems. I'm always amazed to see a 2GHz Core Duo laptop shipped with a 5400RPM (sometimes even 4200RPM) disk.
Mine was, for example. I spent the extra 7% to add an after-market 72kRPM SATA disk (80gb vs 120GB, but hey, the 120GB is still useful in an external enclosure) and the laptop's performance about doubled for many tasks. It's worth every cent. The fact that Apple offer 72kRPM disks in their laptops is one of the biggest reaons, if not the only reason, why they get such excellent benchmark scores, and it astounds me that few other manufacturers are doing it.
It's an accounts and newspaper bookings system. It's writen in a "4GL" called Plain English in 1991. The company that created the runtime had ceased to exist long before the app was writen - we're using Plain English from 1893. I've never been able to comprehend how anybody could choose a proprietary 4GL from a long defunct company for the basis of their new mission-critical app ... especially when it's not very good. I suspect the situation boiled down to the "developer" being incapable of using anything else - he's more of a business systems analyst and accountant than a developer, and my god does it show in the code.
... I get to maintian OpenServer. I think OpenServer is by far and away the best part of the situation, but that doesn't make it nice.
The modern equivalent would be a business system written in VBA on top of Access 1.0 (presuming it had VBA), now, in 2006.
More info in response to another poster too, in case you care.
I inherited this abominable situation and have been trying to find a way to get the business out of it for some time. Doubly so since the creator of the software is becoming more and more unrealiable (think: errattic, alcoholic, drops out of touch for months, etc) and the system needs fixes periodically to keep it running because of the incredibly crap underlying runtime and some bad decisions by the developer of the system its self.
It's being replaced, but because it's so neatly tailored to the business and so important that's a slow process. In the mean time
I don't have the source code. Trust me, if I did, I'd have ported it quite some time ago. As for not having the source ... the person making the decisions when the app was written just wasn't aware of the issues.
The problem is in fact not the application its self - that was custom built and we do have the source - but the runtime it sits on. It's an early database-integrated 4GL called Plain English. The company that wrote the runtime is long dead. In fact, it was out of business more than eight years before the system developed on top of the runtime was developed, and I've never been able to understand how on earth they chose to use this ancient 4GL for the project.
I've actually written a replacement runtime based on the documentation I have on Plain English, but it looks like the code we have relies on quite a bit of undocumented behaviour. It's not well enough written to handle unexpected issues or error conditions successfully - in fact I'd describe it as hideous undocumented spaghetti from hell - so testing is awfully painful. Given the reliability level required it's not a practical approach, and even if it were, I'd just be maintaining hideous spaghetti from hell on top of a new runtime. Um, yay.
Did I mention the integrated database without transaction support that is corrupted if a client unexpectedly disconnects? Same issue with telnet disconnects and the old dumb terminals (no longer used) being turned off - it's just crap software. What about the lovely code-in-database setup that is prone to corruption if the incredibly flakey custom editor runs into any issues? Yes, Plain English is clearly the height of modern software development...
The system is being replaced, but in the mean time, I have to keep OpenServer kicking along. Ugh.
OpenServer (at least v5.0.5 which I have) is weird. It's better documented than Linux is and can ever hope to be - the docs are more consistent, more accurate, more complete, and better written. It's also incredibly stable in most ways - but with a few REALLY annoying quirks. As it's also stable in the same way a fossil is (What, buy and upgrade? Get bent), that's frustrating. It also has some incredibly annoying limitations, a set of developer tools so bad they boggle the mind (and the alternatives aren't great either - haven't got Skunkware's gcc WORKING yet), and some basic services we're used to just being there ... well ... aren't. Oh, and printing on SCO is one of the worst messes I've ever had the misfortune to work with - it makes Linux printing look like heaven, and it's pretty awful too. If you now feel the need to scour your eyes with steel wool, you're not alone.
... and there's always Solaris as an alternative.
... but with a free Solaris, they're just doomed. RHEL and so on help a fair bit with regards to stability in Linux too - something which also doesn't help SCO in the slightest.
I maintain an OpenServer box for work only because of a legacy app that requires it. Well, strictly, the app requires Microsoft Xenix to run - it's from 1983 (!!) - but SCO OpenServer's XENIX kernel personality does the trick with a few quirks. OpenServer at least supports PCI, >16MB RAM, and >512MB disks, unlike XENIX. (OpenServer 5.0.5 actually supports up to 2TB disks/arrays, >137GB ATA disks, etc. Not bad for an OS from 1995). If it weren't for that need - which Linux can't satisfy even with the defunct ibcs project - I'd be rid of OpenServer in an instant. Linux 2.6 isn't as stable as I'd like, but that's worth it
I can't imagine anybody buying OpenServer now. Its only purpose is legacy support. Unixware doesn't even have that. Before Sun released Solaris for free, they had a tiny sliver of hope from people who need more stability than Linux provides
Even if their technology wasn't obsolete crap, who on earth would buy from a company that sues its own customers? Oh, wait, I use Microsoft software at work and I'm well aware of its involvement in the BSA & BSAA so that's no argument at all... but the obsolete crap point holds.
First, mobile phones do have extremely high frequency chips in them. They have to in order to recieve and process the high frequency signals they deal with. Those high frequency chips are a fairly large part of their power draw, too - yet their draw is *tiny* compared to even the simplest CPU of that clock. Remember that clock speed means very little without a consideration of the number of transistors on the chip, energy leakage rates, and lots more I know nothing about.
/., this chip is a very fast very simple unit - not a large microprocessor. I'd guess they're looking into ultra-high-speed signal processing (hence the mobile phone analogy) rather than computer CPUs here.
You're making the erroneous equation that "chip" == CPU, which is far from the case. A phone's CPU may be clocked much lower. Even if it's integrated with the RF chip (I'm not sure this is ever done, is it?), the RF processing parts will be clock-multiplied or the CPU parts will be clock-divided to ensure sensible running frequencies.
I think you'll also find that, contrary to the assumptions made by most posters here on
Yeah, not a bad plan - but it does require FTP, and that pretty much means plain text passwords in the absence of Kerberos or SASL-ized FTP. Ugh.
Still, thanks for the tip. If I create a new special purpose account just for that with some unimportant password, it'd be ok.
I've long wished that Firefox would support LDAP+TLS or WebDAV+TLS (with client certificates) for storing at least bookmarks, if not history. It's amusing that Google seems to have done it for them - the downside being that I can't use my own servers, I have to use Google. I'll still bite.
To be honest, though, what'd be REALLY exciting would be a similar tool for Thunderbird that enabled a secure writeable server side (pref. LDAP) address book, not just the limited read-only LDAP address book support it currently has. If their calendar app added WebDAV+TLS or HTTPs WebDAV remote calendar storage, it'd start to feel like an app made for people who (*gasp*) use more than one computer.
Maybe Google's move here will show the mozilla folks that people are interested in these features.
In fairness, it *does* work using Firefox. So they're doing better than usual. Contrast to Windows Live Safety Centre (http://safety.live.com) which breaks if you even try to do anything in firefox (let alone anything else).
--
Craig Ringer
You got it. Like Java, C# .Net can be fast and efficient. Like Java, if you add Swing (the C# equivalent is Windows Forms) into the mix it becomes a bloated pig in a hurry. Like Java, it takes plenty of skill and thought to write an app that doesn't take a week to load, so you actually can't hire monkeys for programmers.
*sigh*
To be quite frank, the ATi drivers are awful under Windows too. The ATi control center manages to take 25s to load on my 2GHz Core Duo laptop with 2GB of RAM and a 7200rpm hard disk. That's equivalent to an awfully grunty desktop. For all that, it doesn't even do very much, has a terrible UI, doesn't work correctly when Windows is set to use the correct screen DPI not pretend it's a 72dpi display (pathetic for a video card mfgr), and is a bit flakey to boot.
The ATi drivers are absolutely crap no matter what platform you're on.
In theory that's true. In practice, DRM can be made effective enough by making it too difficult to crack for most users. By designing to reduce the chance of breaks across whole models or classes of device (unique keys, anti-tampering, etc etc) and just generally working hard to make it a royal pain to crack each system, they get most of what they want: the average user stops trying and gives up.
Now, in most cases it only takes one break for some file/show/whatever to be made available for everybody. So long as we assume devices can still play "unprotected" content, that's enough to break the effectiveness of the DRM but still make everybody's lives miserable. Everybody loses! I suspect that's what we're headed towards, and the media outfits will keep on using the isolated breaks as an argument for stronger and stronger "protection" and legislative support, then to lock down "unprotected" content, etc etc.
I'm hoping it'll all come crashing off the rails when someone wakes up and sees some sense, but it's not going to do so in a hurry, and the trip in the mean time won't be fun.
Rather a lot.
The ODF Format isnt' a word processor format or spreadsheet format. It's an "office" document container with subformats for a number of major tasks. If they want it to be future proof against the changing needs of users and developers, it needs to be flexible and extensible both within the subformats, and to allow new subformats. Currently, it doesn't seem to be as extensible as it might ideally be, or as extensible as the MS offering (weird, eh?).
Who would've thought when MS Word 2.0 came out that macros (for all their evils) might be a mandatory thing to be able to store in a document? Heck, even images. Who knows what we'll need in future, but I'd prefer a format that can handle whatever gets thrown at it, not one that must be revised each time new requirements arise.
In theory, using XML would be enough to guarantee useful extensibility. In reality that's not so. An application often uses XML as an on-disk format, but doesn't preserve its structure or contents when loading the document into memory, instead converting the document into its own native structures. To save the document, the in-memory data structures are serialized to disk. Unless the program takes great pains to preserve any associated XML data that it doesn't understand, that data is lost. OpenOffice makes no such effort.
There are a couple of ways to do it so that you get to use XML properly, not just as a slightly friendlier on-disk format. One is to work in-memory with a DOM constructed from your XML file. That can work very well, but can also get slow and cumbersome. It can also be very, very memory expensive with large documents.
Another way is to work with the document fairly normally, but preserve any XML structures that aren't understood by associating them with your normal objects. These then get serialized out again on saving, still associated with the right objects; they're deleted when the object is, and so on. It's generally not as nice as using a DOM, but does the job, and if you provide suitable APIs to plugins etc they can still work with this data.
The worst way is to just discard anything you don't explicitly understand on input, and that's what OO.o does. The ODF spec permits apps to do this, and in fact doesn't even suggest that they might do anything else. If the single biggest implementor of the spec will discard all XML that it doesn't directly implement, the format isn't really using XML all that well to my mind. The format specification needs to require that applications preserve foreign markup in order to comply with the spec; failure to do so means one can never know if any given app will strip out parts of your document.
I do know about the XForms support, and I find it very interesting. That said, I just think they need to recognise that they just can't anticipate every possible thing that people might need from the format, and plan for really solid extensibility, rather than just trying to add support for the technology-of-the-day as they go along. I'm astonished and impressed that Microsoft "gets" this, while the ODF folks don't really seem to.
Yep, MS Office loads some code at start-up, or at least older versions did. I can't actually find any running programs or services with Process Explorer or Autoruns to suggest that that's still true in Office 2003, and the first-time load time is quite a bit longer than subsequent executions. I wouldn't be surprised if it just pre-reads the DLLs from disk into cache and leaves it at that (just like most Linux distros now precache the login environment and common programs during boot). Anyway, in the Windows 95 days, when 4MB of RAM was a lot, that preloader was a giant resource hog. I see no evidence on my system that it's still even detectable. Of course, my system with XP running, firefix, thunderbird, and a leaping mound of OEM crap weighs in at a little over 200MB of memory used, so I'm not too stressed. Quitting thunderbird freed 70MB anyway (hooray for memory-efficient IMAP clients?).
;-) I just think the "Office is bloated" argument is old, tired, and no longer relevant due to changes in systems and the programs concerned. Heck, I think these days it might be smaller than emacs ;-)
My experience is that in real-world use MS Office just uses less memory and CPU time to accomplish tasks than OO.o does. MS Office is certainly not lean compared to some of the lighter, smaller and less functional options around, but I've found it to be much less hard on a system than OO.o.
Of course, now I have a 2x2GHz laptop with 2GB of RAM, so I don't really care
While your comment doesn't really deserve the dignity of a reply (especially since you posted AC), I'm going to waste some time and do so anyway.
The simplest reason to want to preserve your own markup is to integrate with other systems. Here's a simplistic example: A content management system may want to store the identity of a document in the document in such a way as that it can be reognised as the same document when re-imported into the CMS after someone's been working on it on some disconnected laptop. Existing metadata may not offer that facility.
Another good case is a plug-in that adds significant functionality to the application and needs to store its data in the document, have it travel with the document, and have its data associated with specific parts of the document. Consider a bibliography editor - if you delete the text with the reference, the editor needs to be able to tell that's happened and not output the associated reference in the full bibilography. Currently such tools maintain their own databases and/or use opaque blobs in the document for this, but these approaches aren't very good - in particular they mean that if the document is edited by a tool that doesn't have the bibliography editor, the information can be lost or damaged.
That's a simplistic example, but in the broader sense it comes down to wanting to be able to do things with a format beyond those that the original designers explicitly considered. Imagine if we still had to use X11 as it was written originally? What a mess. Thankfully, X11 is extensible and well designed so that additions the original designers didn't imagine can be added over time.
A generic, universal "office" document format needs to satisfy that requirement too.
You're kidding, right? MS office is the bloated one, when compared to OpenOffice.org?
Office might've been bloated once, and arguably still is, but it's nothing compared to the awe-inspiring bulk of OO.o in action.