Actually, Beta was technically better than VHS. When I had to switch to VHS I noticed the quality difference. But VHS won because Sony decided to charge the movie companies a royalties. The effect was that the new movies came out on VHS, and only showed up on Beta after market experience suggested that it might be worth paying the royalties for a later Beta version. It didn't take long for consumers to notice that new releases were on VHS, and Beta lost the game entirely.
Lovely processor. Innovative design. I wish it had made it to the so-called desktop, i.e. Windows, which, if you recall, is the subject of this thread. But it didn't, because to run the decade-old legacy software it would have had to interpret the legacy 32-bit instruction set and be really fast at it. That's the obstacle it shares with the ARM. I don't recall the Itanium instruction set in detail, but I had the impression that the Itanium instruction set is better at emulation than most other architectures. So ARM will presumably have a tougher time of it.
The trouble is that you have to choose between a functional language and an imperative language, rather than, within one language, using a functional style when that suits the problem, and an imperative style when that does, and some of each when that does. There's no reason why languages have to choose between being functional or imperative. That should be up the the programmer.
Algol 68 came close to allowing both styles. Surely we should be able to do better after four decades.
They... have to retype their password 10 times until they get it right
They have Parkinson's disease and despair at every password they have to enter. THey never know whether they've remembered the wrong password or just can't type correctly.
Your complaint here seems to be lack of documentation -- the well-known aversion of open-source programmers to document their work. But I suspect something deeper is at work here -- that the implementers of audio subsystems fail to fully understand the demands that are imposed by audio applications, and so that existing subsystems keep having to be replaced by newer ones with newer incompatible, behaviours. But I did just now, while writing this, manage to find a web page, that appears to give an overview of what's available, and a good deal of commentary discussing the mess.
Parent said it -- " I don't even really get how it all works, is supposed to work". And there doesn't seem to be documentation explaining it. Or have I just not found it yet?
What I use Windows for? Mostly Adobe Digital Editions. Ever if I were to crack its DRM, I would still need it to download the actual books. All I get directly from the bookstore is something with a name like "fulfillment certificate". I wish they'd make it run natively on Linux.
Switching to Windows to buy books is a disincentive to purchasing. I end up reading a lot of free classics, free fanfic, and nonDRM'd books from publishers like Baen.
I once gave a reviewing assignment in a graduate class -- only the language used was English, not computer code. Each of the students had a term project they had to do and report on (the projects were all different). I graded the projects. But along the way, each draft of the final report was handed out to several other students for review. Those other students where responsible for providing constructive criticism. I too reviewed the drafts. A student's final grade was based on my grading of his final project and my grading of the reviews the student gave to others. The draft report was not graded.
It took a lot of effort. I can't see how to automate this process. The reviews covered both technical issues and presentation issues. I think the students learned a fair amount; there was a *lot* of improvement between the drafts and final versions.
rdiff-backup keeps old versions around via backwards differences. And if you use it right, the most recent version of a file can just be read from the backup drive without using rdiff-backup.
And it can operate over a network.
According to the docs, it's supposed to be available for mac and windows, too.
I download fanfic, convert it to.epub format using calibre, and put it on my ancient, first-generation kobo. It's a much better reading experience than on my desktop computer. No walled garden. The only problem is that a lot of fanfic is available only in very ugly HTML. Can't blame that on the kobo, though.
2) GoogleDocs. Where's the "share this with my colleagues and let them make updates" function in OpenOffice?
With minor tweaks the.fodt (flat odt) format would suffice. Principally, it needs to have newlines placed into the text at frequent, standard places (such as after every punctuation mark, whereever a short word follow significantly longer one, or something like that) so that it can be handled fairly well by normal version control systems. Oh, there are probably a few other tweaks in the versioning system to preserve XML nesting, but, really, all that's needed is some compatibility with existing document-sharing tools.
Did something change? The link that's supposed to go to your blog post seems to point right back to this article on slashdot instead.
Most likely, it'll start with killing the enemy's GPS and comm satellites to prevent them from supporting ground troops.
It may not even take launches. Much easier and much more useful to break into the satellites' OSes and take them over.
-- hendrik
Actually, Beta was technically better than VHS. When I had to switch to VHS I noticed the quality difference. But VHS won because Sony decided to charge the movie companies a royalties. The effect was that the new movies came out on VHS, and only showed up on Beta after market experience suggested that it might be worth paying the royalties for a later Beta version. It didn't take long for consumers to notice that new releases were on VHS, and Beta lost the game entirely.
Well, there's wikibooks.
Lovely processor. Innovative design. I wish it had made it to the so-called desktop, i.e. Windows, which, if you recall, is the subject of this thread. But it didn't, because to run the decade-old legacy software it would have had to interpret the legacy 32-bit instruction set and be really fast at it. That's the obstacle it shares with the ARM. I don't recall the Itanium instruction set in detail, but I had the impression that the Itanium instruction set is better at emulation than most other architectures. So ARM will presumably have a tougher time of it.
Of course, of course. That was the context I was writing in.
Thanks for the clarification.
I imagine ARM is going to be up against the same problems as the Itanium.
It's Linux without the so-called GNU operating system,
The trouble is that you have to choose between a functional language and an imperative language, rather than, within one language, using a functional style when that suits the problem, and an imperative style when that does, and some of each when that does. There's no reason why languages have to choose between being functional or imperative. That should be up the the programmer.
Algol 68 came close to allowing both styles. Surely we should be able to do better after four decades.
They ... have to retype their password 10 times until they get it right
They have Parkinson's disease and despair at every password they have to enter. THey never know whether they've remembered the wrong password or just can't type correctly.
-- hendrik
Your complaint here seems to be lack of documentation -- the well-known aversion of open-source programmers to document their work. But I suspect something deeper is at work here -- that the implementers of audio subsystems fail to fully understand the demands that are imposed by audio applications, and so that existing subsystems keep having to be replaced by newer ones with newer incompatible, behaviours.
But I did just now, while writing this, manage to find a web page, that appears to give an overview of what's available, and a good deal of commentary discussing the mess.
-- hendrik
Parent said it -- " I don't even really get how it all works, is supposed to work". And there doesn't seem to be documentation explaining it. Or have I just not found it yet?
What I use Windows for? Mostly Adobe Digital Editions. Ever if I were to crack its DRM, I would still need it to download the actual books. All I get directly from the bookstore is something with a name like "fulfillment certificate". I wish they'd make it run natively on Linux.
Switching to Windows to buy books is a disincentive to purchasing. I end up reading a lot of free classics, free fanfic, and nonDRM'd books from publishers like Baen.
-- hendrik
I once gave a reviewing assignment in a graduate class -- only the language used was English, not computer code. Each of the students had a term project they had to do and report on (the projects were all different). I graded the projects. But along the way, each draft of the final report was handed out to several other students for review. Those other students where responsible for providing constructive criticism. I too reviewed the drafts. A student's final grade was based on my grading of his final project and my grading of the reviews the student gave to others. The draft report was not graded.
It took a lot of effort. I can't see how to automate this process. The reviews covered both technical issues and presentation issues. I think the students learned a fair amount; there was a *lot* of improvement between the drafts and final versions.
-- hendrik
rdiff-backup keeps old versions around via backwards differences. And if you use it right, the most recent version of a file can just be read from the backup drive without using rdiff-backup.
And it can operate over a network.
According to the docs, it's supposed to be available for mac and windows, too.
-- hendrik
I download fanfic, convert it to .epub format using calibre, and put it on my ancient, first-generation kobo. It's a much better reading experience than on my desktop computer. No walled garden. The only problem is that a lot of fanfic is available only in very ugly HTML. Can't blame that on the kobo, though.
-- hendrik
2) GoogleDocs. Where's the "share this with my colleagues and let them make updates" function in OpenOffice?
With minor tweaks the .fodt (flat odt) format would suffice. Principally, it needs to have newlines placed into the text at frequent, standard places (such as after every punctuation mark, whereever a short word follow significantly longer one, or something like that) so that it can be handled fairly well by normal version control systems. Oh, there are probably a few other tweaks in the versioning system to preserve XML nesting, but, really, all that's needed is some compatibility with existing document-sharing tools.
-- hendrik
Stallman didn't make Linux possible, BSD did.
Wasn't Linux originally built from MINIX, not BSD?
OK, what's "UX"?
I believe he published a paper on his observations, called something like "Visual Astronomy in the Ultraviolet". You might try looking for it.
-- hendrik
I like to read in bright sunlight on my porch. The kobo is perfect for this because of the epaper screen.
Thanks for the link. It looks useful.
I just wish I could program the kobo.
-- hendrik
Yes. Modula 3, for example. has
Mandatory bounds checking, garbage collection and all that implies, and inability to break type safety combined with good execution speed
.
Prove all things
Yeah, but most moderns don't realize that that's "prove" in its old-fashioned sense of "test". Once your realize that, it makes sense.
A related, but different, modern saying is, "That which is not tested is broken".