Figuring out the entropy of the signature is harder than that, though. Let's suppose your grid is 120x120 (that's the PalmPilot, so it's realistic). Let's say my signature is a straight line covering half the display -- 60 pixels with about one bit per pixel (because my hand will wander up and down about one pixel for every one I traverse).
Sixty bits is actually getting halfway reasonable, but there's more -- my speed in making the signature is also characteristic. You're ignoring that in your (lack of) analysis. I'm not going to attach numbers to that for now; the speed there can vary immensely, though, so it's a substantial factor.
This pseudo-analysis ignores the fact that most people don't sign with an almost straight line at constant drawing speed, but rather sign something which once looked like their name. Thus, 60 bits is a strict lower bound.
And do you know what the worst part is? The signature isn't part of the key -- it's transmitted fully publicly. The signature is simply a visual (and technicly analysable) proof that the person who originally registered the appropriate password actually approved of the document. This is something that normal authentication systems don't have -- a means of checking what person is associated with the secret key.
In order to compromise this system, an external attack would have to discover the passphrase AND forge the signature well enough to both look recognisable and analyse as belonging to the victim.
Now, I can see a cool internal attack: capture your own signature, macro it, and use the same signature to sign two letters, one of which is trivial and in your control, the other of which you use to get something, then when payment is requested you dispute it on the basis that the signature is an obvious electronic copy of the one on this other letter.
In other words, forgery remains the same basic problem, but it seems a little easier to fight now, since the signature can be completely analysed (including speed info) and there's a passphrase/secret key involved.
Figuring out the entropy of the signature is harder than that, though. Let's suppose your grid is 120x120 (that's the PalmPilot, so it's realistic). Let's say my signature is a straight line covering half the display -- 60 pixels with about one bit per pixel (because my hand will wander up and down about one pixel for every one I traverse).
Sixty bits is actually getting halfway reasonable, but there's more -- my speed in making the signature is also characteristic. You're ignoring that in your (lack of) analysis. I'm not going to attach numbers to that for now; the speed there can vary immensely, though, so it's a substantial factor.
This pseudo-analysis ignores the fact that most people don't sign with an almost straight line at constant drawing speed, but rather sign something which once looked like their name. Thus, 60 bits is a strict lower bound. Considering that this digital signature method also depends on a pregenerated key (passphrase protected), this signature seems to me to be quite solid (in theory; of course, we know that the code isn't public).
Now, you point out that Joe User is revealing parst of his private key with every signature. This is true, but with the addition of the preencoded key brute-forcing the signature becomes very unattractive.
Why do you assume that the signature is stored or used as a bitmap? That would not only be more expensive in terms of storage, it would remove the ordering and speed information from the strokes.
A shape forgery is reasonably easy. A shape, style, and speed forgery, OTOH, is unprecedented.
At the same time, I can see an opportunity for me to forge my own signature -- I could record my signature and hack it into the Palm, and make the PalmOS imitate that exact pen movement whenever I enter a grafitti stroke. Then I can deny that I signed a given document, and show reasonable doubt by demonstrating that someone could have used the pen echo.
I don't see much chance for someone aside from me being able to steal my authentication, though. Even with that signature imitator, they'd still have to get my Palm away from me (here, Billy! Here's a free Palm Vx!) and get me to tell them my passcode.
Carbon dating showed that it was 3,000 years old, not 20,000 (according to the article). That's in the accurate range of carbon dating, since we have known-age tests from that long ago. (Darn, that was RECENT.)
I hope they post followups about what they find. That's a BIG freezer out there! What was the diet of the old wooly mammoths? How did this one die? So many cool questions...
I hate to use this word, but it's a matter of synergy. WinCE machines have TONS of cool stuff; they have the features computer buyers look for, in spades.
PalmOS machines, OTOH, just work. They don't try to act like computers, they just work.
This is why they can win even in a review so otherwise ignorant as to give WinCE the edge in every individual category. (If the categories were better reviewed PalmOS would win in more of them.)
As for Grafitti -- people who prefer Jot to it are simply excercising their rights to have a closed mind. No offence, I hope. Spend a few minutes learning Grafitti and it's just as good.
Calligrapher, OTOH, is a different matter -- it's quite possible that some people can't handle switching back and forth. I've never met anyone like that, but I have heard people say that they didn't like doing it. WinCE has the edge there; PalmOS machines lack the power to do full HWR. I guess it's a fair choice -- do you want full HWR or long battery life?
Try before you buy. I like full HWR too, but it sure is nice to not have to mess with batteries.
I haven't heard anything about GJC (the port of gcc to compile Java and/or Java bytecodes) recently -- isn't it an acceptable alternative to a JIT? On a different topic, has anyone integrated Java with SOAP or XML/RPC? (They're roughly the same thing -- XML/RPC handles RPC in a reasonably portable way, and SOAP extends that to objects in a quite nice way.) -Billy
I know there are differences in the open/free software community, but what exactly is the *technical* difference? And what is the *philosophical* difference?
Good question. Warning: like everyone here, I'm biased, so I'm going to make a longer post which hopefully will be less offensive than a less thought-out post by me would be. Please pardon (and correct!) any offensive, incorrect statements or stereotypes. My bias is towards Open Source.
The technical difference is partly that the Free Software definition is more specific, and partly that the Free Software community has grown around the GPL (so Free Software projects tend to use the GPL).
The philoosophical difference is related -- the Free Software definition is much narrower partially because they're more idealistic (hence the more specific requirements for freedom) and partially because they're more pragmatic (hence the stronger restrictions in the most commonly used license, the GPL).
The Free Software movement practices the theory that freedom must be assured with law (GPL) as well as action.
The Open Source community, on the other hand, has at its core the theory that freedom cannot be assured by law in all cases, but must always be fought for in person.
As I mentioned, though, the Open Source definition is a lot less specific, so outside of the core of the Open Source community people often hold wildly varying theories. The only one universally accepted is that free/open source software development is more efficient than proprietary software development.
This particular belief is part of the friction between the Free Software and Open Source communities, with FS people posting violent diatribes against the pragmatism of OSS, and OSS people posting equally violent rebuttals claiming their love for freedom.
It's important to recognise that the heart of the OSS movement has the same goals as the Free Software movement.
And the good news -- as far as I can see, they're both winning.
This may indeed take only two lawsuits to demolish -- but the odds of it ever being fought out in court are between slim and none. A patent lawsuit costs a _minimum_ of US$500,000 for both sides.
We're not going to be able to afford that, and odds are Amazon is going to license it for cheaper than that to companies.
Depressing.
(This info courtesy of the CTO at Hi/fn, who has 12 patents to his name, one of them court-proven against MS -- the famous Stac compression patent.)
It's notable that although all of the Palms since the Palm III have been flash upgradable, not a single flash upgrade has ever been released.
The 3.3 OS is supposed to be a flash upgrade, but it seems that it will only work on IIIx'es and later. Its main advantage appears to be faster hotsyncing, something which the Visor already provides (thanks to the USB).
So although lack of flash upgradability IS a negative, I don't see it as mattering that much -- in the light of past experience.
Nice to see a response that was ridden with zealotry. But one correction:
I'll assume you meant "wasn't":-), since that was my intent. Thank you. Although I do have to say that many of the other posts have been very low on zealotry; I just wanted to cover some of the things they hadn't.
You're also right about Workstation being the only NT limited to 2GB. Thanks for the correction.
As we might expect, this document has a lot of errors and a lot of useful information. I haven't seen any attempts at critiques, so I'll go through myself.
I'll categorise each point as good (a valid criticism which we can address), bad (a valid criticism which we can't fix), or ugly (an invalid or pointless criticism). Unfortunately, I won't distinguish between 'ugly' fixable and 'ugly' unfixable; this is the nature of us hackers.
I'm going to mention mainly 'good' things here, because everyone else has covered where MS is wrong;-). I'm concerned more about where they're right.
good: Linux was not designed from the ground-up to support symmetrical multiprocessing (SMP). We can fix this byte by byte, painfully. However, it's not a shortcoming to users; it's a shorcoming to those of us working on adding SMP.
good: graphical user interfaces (GUI). Designing a GUI into the OS isn't good. Designing an OS _for_ a GUI would be great, but NT wasn't built that way. Linux can be built this way, but we're not going to do it -- there's too many advantages to being Unix-like.
good: asynchronous I/O. NT I/O is asynchronous, meaning that an app can request I/O and then go do something else. Linux requires that each I/O request either shut the task down, or force the task to poll. And then you have the good old "thundering herd" problem which was so recently fixed.
ugly: NT supports 4GB of memory. No it doesn't -- it supports two gigs protected, and sets aside two gigs for shared memory.
ugly: The Linux community continues to promise major SMP and performance improvements. And we continue to deliver.
ugly: Linux isn't reliable. Um... Right. Either NT has a low TCO, or it's reliable. Never both. Linux, OTOH, has a low TCO at the same time as it's reliable.
bad: Linux is risky. Or more accurately, risk control takes a little more thought. I mark this as 'bad' because it's not a programmer issue -- it's marketing.
ugly: Linux is insecure. I hate to slam this one, because it's also a good point (I hope we continue improving). However, NT's security system is at best baroque -- it's capable of more security, but it takes so much effort to get that security it's not funny. Add in automatic update for handling security fixes, as with Debian, and you get real power.
ugly: Linux does not provide support for the broad range of hardware in use today; Windows NT 4.0 currently supports over 39,000 systems and devices on the Hardware Compatibility List. Linux does not support important ease-of-use technologies such as Plug and Play, USB, and Power Management. This one's cleverly worded -- they fail to note that NT doesn't support the things which they proudly proclaim that Linux doesn't support.
I'm trying to cover mainly things which others didn't already -- although due to my multitasking someone likely beat me to it. Well, I make do with what I've got.
I would recommend wxWindows for this. The big negative to this is that wxWindows is not _yet_ ported to Qt and GTK; however, both ports are ongoing. The Curses port is also ongoing (although unlike the others, its status is uncertain). (I want that Curses port!!)
It does work on Motif, Lesstif, Xt, and GTK, so it'll run on just about every Linux box. It also works on Windows, and a Mac port is underway.
Also, it's been ported to a scripting language -- Python's implementation is an almost direct echo of its C++ version, to make it easier to transfer knowledge.
BTW, I've never used MFC, but I've heard that wxWindows isn't anything like that. Yet some people here are saying that it's similar. Is that true?
Your point is eloquently put, but I disagree. What you want isn't everything in one document; what you want is for convenient access to all the information via scroll bar.
IBM's solution clearly fails to provide that (there's no way a server-side solution could), which is why I said it falls short.
But that doesn't mean that the optimum solution is a single web page -- the problem there, as always, is that on each monitor screen (or printout page) you get partial chunks of information. This can be as trivial as half-visible lines or as nasty as huge tables sliced into incoherent parts.
The true solution is on the client side.
Ooops, I said you were wrong. Well, really, you're not. Single-document is the way to go whenever possible. It's just that it isn't the solution to this problem, only an essential part of the correct solution.
I claimed that even the best-written HTML wouldn't be well-presentable on devices of widely varying screen sizes.
This is because, among other problems, people don't like to be shown part of a set of information. HTML implicitly assumes that every web page (HTML file) is a single viewer page, but not even my 21" screen will show all of most web pages (so most pages can't possibly be a single page).
The problem only gets worse when you add small screen sizes, such as the Pilot.
The solution is to be a little smarter about displaying information -- you have to think about how much your user can see at once, and be careful not to show them any half-lines of info or half-table cells. Essentially, you should do a single page of repagination every time the user presses the down arrow or pagedown.
Instead of doing this, modern file display programs either assume that their only job is to display the entire document (HTML, less, MS Word in draft mode) or only display optimally for a single page size which almost no users have on their monitors (Acrobat, Word in page preview, ghostscript).
This IBM server is interesting because it forces a current format to be reasonably presented on multiple device -- or window -- sizes. It doesn't remove the need for a real document reader, but it sure is better than we've had before.
This would be nice, but it's not completely true. If you write plain _text_ HTML containing nothing but essential information presented in a way which will fit usefully on the smallest possible screen you won't have a problem (except, of course, people with large screens will get very bored reading little droplets of information at a time).
Otherwise, HTML's habit of treating the entire file as a single page creates terrible viewing problems which only get worse on smaller screens.
This would be fixed by a standard which treated your browser window/viewport as an entire page, and formatted accordingly.
This might also get rid of some of the problems with people printing out stuff all the time -- they do that precisely because there's no document format which presents each view of the document as a complete page, with document progress indicators and links and everything.
In other words, if you change the width of your window, the document instantly repaginates.
I suspect I'm not being very clear at this point -- let me know if I'm making sense to anyone.
I agree with you entirely, but you'll notice how in my previous posts I've been very circumspect about never calling certain lawyers unprintable names, or accusing them of being total bozos, or pointing out their utter incompetence, or claiming that they couldn't find their ass with both hands in a locked, lighted closet with a military GPS reciever.
If I were to have done any of that, I might be sued. Fortunately, I'm clever and quick. They'll never find me making fun of them.
Unfortunately, I *think* signing up with so many would violate most of the firms' contracts... Of course, if you have enough money they'll write new contracts for you.
I do think that it would work, though! Scary. Of course, it doesn't protect you from criminal charges... And anyone can get nailed by Tax Evasion (heck, I evade all the taxes I can!;-).
When I submitted this story, I included some more cool details:
First of all, the lawyers doing the suing are the same folks who sue corparations when their stock goes down.
Second, it turns out that one of the corparations being sued here, 4kids, was dropped from the lawsuit because -- guess what -- their defence firm turned out to be the same firm that was doing the suing!
Those lawyers were evidently unable to check to see that the corporation that they were suing was one of their clients.
The problem with this otherwise insightful post is that you overlook the fact that MS is doing all of this bad stuff _already_. Without selling software-as-service.
And under NO model do you own software -- it's always owned by the copyright owner, and licensed to you.
I do share your concern, though, about the level of intrusion MS will carry out. I think it can be done without the intrusion, but they haven't hired me yet;-).
-Billy (sell out? Gladly. I grew my new beard just for that purpose after watching Matrix...)
This "softare as service" is something I've been expecting ever since I read the Cathedral and the Bazaar. ESR explains the need for it even more clearly in The Magic Cauldron, although he doesn't state that it's useful for proprietary software.
Read the essay, and note how software as service has the _potential_ to overcome the worst of the defects in the traditional software model.
Of course, this doesn't allow proprietary SW to overpower free software, but it does remove its greatest instability. Probably the best part of this move is that the need for agressive growth in order to survive will quite likely be removed. MS will be able to stop attacking and still make good money.
Now, I've analyzed this as a big shot in the arm for proprietary software. And so it is! But it's not bad for free software either, because as more people come to understand that software maintainance is the thing you're paying for, they'll come to understand that the code itself is a weapon in the hands of their enemy only when it's secret.
I'm very optimistic about this, for both free software and proprietary software. And best of all, for programmers' salaries -- this model change may removed the much-bandied about salary drop that even RMS sees as inevitable because of free software.
Software users of the world -- UNITE! You have nothing to lose but your chains.
A discussion of the many ways in which MS can mess this beautiful thing up is, of course, beyond the scope of this editorial.;-). I'm sure others will cover the problem.
The solution to this legally may be as simple as making sure all the beta testers recieve full source code, since that way everyone included in the distribution has their full GPL rights.
Of cours,e a lot of people are going to get mad at them, but nobody will be able to sue them.
The hard part is going to be when someone violates their NDA by distributing the beta. Legally, that would be wrong -- but Corel can't afford to enforce it. That's a tough one.
Sometimes the task may be complicated enough to require the resources of the entire VM, so compiling wouldn't bring any improvement.
However, native code is always an improvement (instead of bytecode).
Makes me wish Juice had been more sucessfull... (Juice was/is the platform-independant binary format used for Oberon; its loader translated it quickly to native code). The current equivalent of Juice is ANDF.
Slashdot Mirror
Figuring out the entropy of the signature is harder than that, though. Let's suppose your grid is 120x120 (that's the PalmPilot, so it's realistic). Let's say my signature is a straight line covering half the display -- 60 pixels with about one bit per pixel (because my hand will wander up and down about one pixel for every one I traverse).
Sixty bits is actually getting halfway reasonable, but there's more -- my speed in making the signature is also characteristic. You're ignoring that in your (lack of) analysis. I'm not going to attach numbers to that for now; the speed there can vary immensely, though, so it's a substantial factor.
This pseudo-analysis ignores the fact that most people don't sign with an almost straight line at constant drawing speed, but rather sign something which once looked like their name. Thus, 60 bits is a strict lower bound.
And do you know what the worst part is? The signature isn't part of the key -- it's transmitted fully publicly. The signature is simply a visual (and technicly analysable) proof that the person who originally registered the appropriate password actually approved of the document. This is something that normal authentication systems don't have -- a means of checking what person is associated with the secret key.
In order to compromise this system, an external attack would have to discover the passphrase AND forge the signature well enough to both look recognisable and analyse as belonging to the victim.
Now, I can see a cool internal attack: capture your own signature, macro it, and use the same signature to sign two letters, one of which is trivial and in your control, the other of which you use to get something, then when payment is requested you dispute it on the basis that the signature is an obvious electronic copy of the one on this other letter.
In other words, forgery remains the same basic problem, but it seems a little easier to fight now, since the signature can be completely analysed (including speed info) and there's a passphrase/secret key involved.
Signed, BilOey JnxlY
(William Tanksley)
Figuring out the entropy of the signature is harder than that, though. Let's suppose your grid is 120x120 (that's the PalmPilot, so it's realistic). Let's say my signature is a straight line covering half the display -- 60 pixels with about one bit per pixel (because my hand will wander up and down about one pixel for every one I traverse).
Sixty bits is actually getting halfway reasonable, but there's more -- my speed in making the signature is also characteristic. You're ignoring that in your (lack of) analysis. I'm not going to attach numbers to that for now; the speed there can vary immensely, though, so it's a substantial factor.
This pseudo-analysis ignores the fact that most people don't sign with an almost straight line at constant drawing speed, but rather sign something which once looked like their name. Thus, 60 bits is a strict lower bound. Considering that this digital signature method also depends on a pregenerated key (passphrase protected), this signature seems to me to be quite solid (in theory; of course, we know that the code isn't public).
Now, you point out that Joe User is revealing parst of his private key with every signature. This is true, but with the addition of the preencoded key brute-forcing the signature becomes very unattractive.
Signed, BilOey JnxlY
(William Tanksley)
Why do you assume that the signature is stored or used as a bitmap? That would not only be more expensive in terms of storage, it would remove the ordering and speed information from the strokes.
A shape forgery is reasonably easy. A shape, style, and speed forgery, OTOH, is unprecedented.
At the same time, I can see an opportunity for me to forge my own signature -- I could record my signature and hack it into the Palm, and make the PalmOS imitate that exact pen movement whenever I enter a grafitti stroke. Then I can deny that I signed a given document, and show reasonable doubt by demonstrating that someone could have used the pen echo.
I don't see much chance for someone aside from me being able to steal my authentication, though. Even with that signature imitator, they'd still have to get my Palm away from me (here, Billy! Here's a free Palm Vx!) and get me to tell them my passcode.
-Billy
Carbon dating showed that it was 3,000 years old, not 20,000 (according to the article). That's in the accurate range of carbon dating, since we have known-age tests from that long ago. (Darn, that was RECENT.)
I hope they post followups about what they find. That's a BIG freezer out there! What was the diet of the old wooly mammoths? How did this one die? So many cool questions...
-Billy
I hate to use this word, but it's a matter of synergy. WinCE machines have TONS of cool stuff; they have the features computer buyers look for, in spades.
PalmOS machines, OTOH, just work. They don't try to act like computers, they just work.
This is why they can win even in a review so otherwise ignorant as to give WinCE the edge in every individual category. (If the categories were better reviewed PalmOS would win in more of them.)
As for Grafitti -- people who prefer Jot to it are simply excercising their rights to have a closed mind. No offence, I hope. Spend a few minutes learning Grafitti and it's just as good.
Calligrapher, OTOH, is a different matter -- it's quite possible that some people can't handle switching back and forth. I've never met anyone like that, but I have heard people say that they didn't like doing it. WinCE has the edge there; PalmOS machines lack the power to do full HWR. I guess it's a fair choice -- do you want full HWR or long battery life?
Try before you buy. I like full HWR too, but it sure is nice to not have to mess with batteries.
-Billy
I haven't heard anything about GJC (the port of gcc to compile Java and/or Java bytecodes) recently -- isn't it an acceptable alternative to a JIT? On a different topic, has anyone integrated Java with SOAP or XML/RPC? (They're roughly the same thing -- XML/RPC handles RPC in a reasonably portable way, and SOAP extends that to objects in a quite nice way.) -Billy
You miss the fact that the person asking had requested info on the difference between Free Software and Open Source Software.
_Both_ models have freedom at their heart. Neither one is right to attack the other by claiming otherwise.
So although your post is entirely right, it misses the point by failing to name the differences between the two camps.
-Billy
I know there are differences in the open/free software community, but what exactly is the *technical* difference? And what is the *philosophical* difference?
Good question. Warning: like everyone here, I'm biased, so I'm going to make a longer post which hopefully will be less offensive than a less thought-out post by me would be. Please pardon (and correct!) any offensive, incorrect statements or stereotypes. My bias is towards Open Source.
The technical difference is partly that the Free Software definition is more specific, and partly that the Free Software community has grown around the GPL (so Free Software projects tend to use the GPL).
The philoosophical difference is related -- the Free Software definition is much narrower partially because they're more idealistic (hence the more specific requirements for freedom) and partially because they're more pragmatic (hence the stronger restrictions in the most commonly used license, the GPL).
The Free Software movement practices the theory that freedom must be assured with law (GPL) as well as action.
The Open Source community, on the other hand, has at its core the theory that freedom cannot be assured by law in all cases, but must always be fought for in person.
As I mentioned, though, the Open Source definition is a lot less specific, so outside of the core of the Open Source community people often hold wildly varying theories. The only one universally accepted is that free/open source software development is more efficient than proprietary software development.
This particular belief is part of the friction between the Free Software and Open Source communities, with FS people posting violent diatribes against the pragmatism of OSS, and OSS people posting equally violent rebuttals claiming their love for freedom.
It's important to recognise that the heart of the OSS movement has the same goals as the Free Software movement.
And the good news -- as far as I can see, they're both winning.
-Billy
Try a search on Google, compare it to the other search sites, and then tell us that it's the same.
It's not the same -- Google manages the meanings of the links as well as the number of links.
I'm not saying that I'm sure Google's patents are good, but I see no evidence to suggest otherwise.
-Billy
This may indeed take only two lawsuits to demolish -- but the odds of it ever being fought out in court are between slim and none. A patent lawsuit costs a _minimum_ of US$500,000 for both sides.
We're not going to be able to afford that, and odds are Amazon is going to license it for cheaper than that to companies.
Depressing.
(This info courtesy of the CTO at Hi/fn, who has 12 patents to his name, one of them court-proven against MS -- the famous Stac compression patent.)
-Billy
It's notable that although all of the Palms since the Palm III have been flash upgradable, not a single flash upgrade has ever been released.
The 3.3 OS is supposed to be a flash upgrade, but it seems that it will only work on IIIx'es and later. Its main advantage appears to be faster hotsyncing, something which the Visor already provides (thanks to the USB).
So although lack of flash upgradability IS a negative, I don't see it as mattering that much -- in the light of past experience.
-Billy
Nice to see a response that was ridden with zealotry. But one correction:
:-), since that was my intent. Thank you. Although I do have to say that many of the other posts have been very low on zealotry; I just wanted to cover some of the things they hadn't.
I'll assume you meant "wasn't"
You're also right about Workstation being the only NT limited to 2GB. Thanks for the correction.
-Billy
As we might expect, this document has a lot of errors and a lot of useful information. I haven't seen any attempts at critiques, so I'll go through myself.
;-). I'm concerned more about where they're right.
I'll categorise each point as good (a valid criticism which we can address), bad (a valid criticism which we can't fix), or ugly (an invalid or pointless criticism). Unfortunately, I won't distinguish between 'ugly' fixable and 'ugly' unfixable; this is the nature of us hackers.
I'm going to mention mainly 'good' things here, because everyone else has covered where MS is wrong
good: Linux was not designed from the ground-up to support symmetrical multiprocessing (SMP). We can fix this byte by byte, painfully. However, it's not a shortcoming to users; it's a shorcoming to those of us working on adding SMP.
good: graphical user interfaces (GUI). Designing a GUI into the OS isn't good. Designing an OS _for_ a GUI would be great, but NT wasn't built that way. Linux can be built this way, but we're not going to do it -- there's too many advantages to being Unix-like.
good: asynchronous I/O. NT I/O is asynchronous, meaning that an app can request I/O and then go do something else. Linux requires that each I/O request either shut the task down, or force the task to poll. And then you have the good old "thundering herd" problem which was so recently fixed.
ugly: NT supports 4GB of memory. No it doesn't -- it supports two gigs protected, and sets aside two gigs for shared memory.
good: asynchronous I/O, completion ports, and fine-grained kernel locks. Let's add 'em!
ugly: The Linux community continues to promise major SMP and performance improvements. And we continue to deliver.
ugly: Linux isn't reliable. Um... Right. Either NT has a low TCO, or it's reliable. Never both. Linux, OTOH, has a low TCO at the same time as it's reliable.
bad: Linux is risky. Or more accurately, risk control takes a little more thought. I mark this as 'bad' because it's not a programmer issue -- it's marketing.
ugly: Linux is insecure. I hate to slam this one, because it's also a good point (I hope we continue improving). However, NT's security system is at best baroque -- it's capable of more security, but it takes so much effort to get that security it's not funny. Add in automatic update for handling security fixes, as with Debian, and you get real power.
ugly: Linux does not provide support for the broad range of hardware in use today; Windows NT 4.0 currently supports over 39,000 systems and devices on the Hardware Compatibility List. Linux does not support important ease-of-use technologies such as Plug and Play, USB, and Power Management. This one's cleverly worded -- they fail to note that NT doesn't support the things which they proudly proclaim that Linux doesn't support.
I'm trying to cover mainly things which others didn't already -- although due to my multitasking someone likely beat me to it. Well, I make do with what I've got.
-Billy
I would recommend wxWindows for this. The big negative to this is that wxWindows is not _yet_ ported to Qt and GTK; however, both ports are ongoing. The Curses port is also ongoing (although unlike the others, its status is uncertain). (I want that Curses port!!)
It does work on Motif, Lesstif, Xt, and GTK, so it'll run on just about every Linux box. It also works on Windows, and a Mac port is underway.
Also, it's been ported to a scripting language -- Python's implementation is an almost direct echo of its C++ version, to make it easier to transfer knowledge.
BTW, I've never used MFC, but I've heard that wxWindows isn't anything like that. Yet some people here are saying that it's similar. Is that true?
-Billy
Your point is eloquently put, but I disagree. What you want isn't everything in one document; what you want is for convenient access to all the information via scroll bar.
IBM's solution clearly fails to provide that (there's no way a server-side solution could), which is why I said it falls short.
But that doesn't mean that the optimum solution is a single web page -- the problem there, as always, is that on each monitor screen (or printout page) you get partial chunks of information. This can be as trivial as half-visible lines or as nasty as huge tables sliced into incoherent parts.
The true solution is on the client side.
Ooops, I said you were wrong. Well, really, you're not. Single-document is the way to go whenever possible. It's just that it isn't the solution to this problem, only an essential part of the correct solution.
-Billy
I claimed that even the best-written HTML wouldn't be well-presentable on devices of widely varying screen sizes.
This is because, among other problems, people don't like to be shown part of a set of information. HTML implicitly assumes that every web page (HTML file) is a single viewer page, but not even my 21" screen will show all of most web pages (so most pages can't possibly be a single page).
The problem only gets worse when you add small screen sizes, such as the Pilot.
The solution is to be a little smarter about displaying information -- you have to think about how much your user can see at once, and be careful not to show them any half-lines of info or half-table cells. Essentially, you should do a single page of repagination every time the user presses the down arrow or pagedown.
Instead of doing this, modern file display programs either assume that their only job is to display the entire document (HTML, less, MS Word in draft mode) or only display optimally for a single page size which almost no users have on their monitors (Acrobat, Word in page preview, ghostscript).
This IBM server is interesting because it forces a current format to be reasonably presented on multiple device -- or window -- sizes. It doesn't remove the need for a real document reader, but it sure is better than we've had before.
-Billy
This would be nice, but it's not completely true. If you write plain _text_ HTML containing nothing but essential information presented in a way which will fit usefully on the smallest possible screen you won't have a problem (except, of course, people with large screens will get very bored reading little droplets of information at a time).
Otherwise, HTML's habit of treating the entire file as a single page creates terrible viewing problems which only get worse on smaller screens.
This would be fixed by a standard which treated your browser window/viewport as an entire page, and formatted accordingly.
This might also get rid of some of the problems with people printing out stuff all the time -- they do that precisely because there's no document format which presents each view of the document as a complete page, with document progress indicators and links and everything.
In other words, if you change the width of your window, the document instantly repaginates.
I suspect I'm not being very clear at this point -- let me know if I'm making sense to anyone.
-Billy
I agree with you entirely, but you'll notice how in my previous posts I've been very circumspect about never calling certain lawyers unprintable names, or accusing them of being total bozos, or pointing out their utter incompetence, or claiming that they couldn't find their ass with both hands in a locked, lighted closet with a military GPS reciever.
If I were to have done any of that, I might be sued. Fortunately, I'm clever and quick. They'll never find me making fun of them.
:-)
Accrding to the Union Tribune article about this suit, it is the same lawyer firm. So you're not just seeing things.
:-)
-Billy
That's a great idea (and a really cool .sig).
;-).
Unfortunately, I *think* signing up with so many would violate most of the firms' contracts... Of course, if you have enough money they'll write new contracts for you.
I do think that it would work, though! Scary. Of course, it doesn't protect you from criminal charges... And anyone can get nailed by Tax Evasion (heck, I evade all the taxes I can!
-Billy
When I submitted this story, I included some more cool details:
First of all, the lawyers doing the suing are the same folks who sue corparations when their stock goes down.
Second, it turns out that one of the corparations being sued here, 4kids, was dropped from the lawsuit because -- guess what -- their defence firm turned out to be the same firm that was doing the suing!
Those lawyers were evidently unable to check to see that the corporation that they were suing was one of their clients.
Source: Union Tribune, "Law firm sues own client."
-Billy
The problem with this otherwise insightful post is that you overlook the fact that MS is doing all of this bad stuff _already_. Without selling software-as-service.
;-).
And under NO model do you own software -- it's always owned by the copyright owner, and licensed to you.
I do share your concern, though, about the level of intrusion MS will carry out. I think it can be done without the intrusion, but they haven't hired me yet
-Billy (sell out? Gladly. I grew my new beard just for that purpose after watching Matrix...)
:-)
Read the essay, and note how software as service has the _potential_ to overcome the worst of the defects in the traditional software model.
Of course, this doesn't allow proprietary SW to overpower free software, but it does remove its greatest instability. Probably the best part of this move is that the need for agressive growth in order to survive will quite likely be removed. MS will be able to stop attacking and still make good money.
Now, I've analyzed this as a big shot in the arm for proprietary software. And so it is! But it's not bad for free software either, because as more people come to understand that software maintainance is the thing you're paying for, they'll come to understand that the code itself is a weapon in the hands of their enemy only when it's secret.
I'm very optimistic about this, for both free software and proprietary software. And best of all, for programmers' salaries -- this model change may removed the much-bandied about salary drop that even RMS sees as inevitable because of free software.
Software users of the world -- UNITE! You have nothing to lose but your chains.
A discussion of the many ways in which MS can mess this beautiful thing up is, of course, beyond the scope of this editorial. ;-). I'm sure others will cover the problem.
-Billy
The solution to this legally may be as simple as making sure all the beta testers recieve full source code, since that way everyone included in the distribution has their full GPL rights.
Of cours,e a lot of people are going to get mad at them, but nobody will be able to sue them.
The hard part is going to be when someone violates their NDA by distributing the beta. Legally, that would be wrong -- but Corel can't afford to enforce it. That's a tough one.
-Billy
Sometimes the task may be complicated enough to require the resources of the entire VM, so compiling wouldn't bring any improvement.
However, native code is always an improvement (instead of bytecode).
Makes me wish Juice had been more sucessfull... (Juice was/is the platform-independant binary format used for Oberon; its loader translated it quickly to native code). The current equivalent of Juice is ANDF.
-Billy